User Acquisition: UA Base
User Acquisition mechanisms in production today in the mobile space, and more specifically in the Android space, don't focus in improving users' experience. Android app developers have a hard time reaching end users and increasing their user base.
The AppCoins Protocol proposes a different approach, where users are rewarded for installing and actually using apps, being this behaviour tracked by the blockchain. Developers can create campaigns in the protocol for their apps and every time an attribution takes place, the users are automatically rewarded. In order to prove that a user actually used the an app, the AppCoins Protocol proposes a Proof-of-Attention (PoA) mechanism, which states that the user spent at least 2 minutes using the app.
Different frontend solutions to display the available campaigns (offer walls) can be built on top of the protocol. An example relying exclusively in the smart contract managing campaign creation in the protocol can be seen here.
Below is a diagram showing the different artefacts that compose the User Acquisition use case in its most pure form (i.e. not relying on any third-party except for the Ethereum Blockchain), and the interactions between them that make possible that developers reward users for using their apps.
The artefacts from the AppCoins Project used in the User Acquisition use case are:
- ASF SDK (official documentation)
- ASF Wallet (Google Play & Aptoide)
- AppCoins token smart contract (Mainnet & Ropsten)
- User Acquisition smart contract (Mainnet & Ropsten)
A developer interested in promoting his application through the User Acquisition mechanism is required to register a campaign in the blockchain. Thus, campaign registration can be done through a web frontend. An example relying exclusively in the smart contract can be seen here.
In order to create a user acquisition campaign, a developer must provide the following information:
| Name | Description |
|---|---|
| Package name | Package name of the app promoted in the campaign |
| Start date | Date on which the campaign will start to be valid |
| End date | Date on which the campaign will no longer be valid |
| Price | Value the developer is willing to pay for a single user acquisition |
| Budget | Total value a developer is willing to pay for the campaign |
| App Vercode | Version codes of the app which are include in the user acquisition campaign |
| Country list | Countries where the campaign is valid (For country encoding see asf-contracts wiki) |
Creating a campaign is also possible directly using createCampaign function from Advertisement smart contract.
createCampaign ( string packageName, uint[3] countries, uint[] vercodes, uint price, uint budget, uint startDate, uint endDate)
Once a campaign is created, events CampaignCreated and CampaignInformation are emitted.
event CampaignCreated( bytes32 bidId, uint price, uint budget, uint startDate, uint endDate, bool valid, address owner );
event CampaignInformation( bytes32 bidId, address owner, string ipValidator, string packageName, uint[3] countries, uint[] vercodes);
An offer wall is presented as a web frontend enabling a user to access user acquisition campaigns. As presented a demo of this feature can be found here. Through a offer wall a user is expected to get all active campaigns and download applications subject to user acquisition campaigns. An offer wall is expected to have the following information, for each campaign:
- Application name
- Application's developer name
- Reward a user gets for a proof of attention submission
Once a user downloads an application from the offer wall and opens it for the first time, a proof of attention is calculated. Any offer wall is required to rely on a service to obtain campaign information, as the smart contract do not provide any methods to get Application's developer, name or package name. This information can be obtained by reading Ethereum blockchain events emitted from the Advertisement contract.
Considering a base specification for user acquisition, a proof of attention is computed through the ASF SDK, once a supported application is opened by a user for the first time. A proof of attention is computed during the time a user is using the application and ends it's computation after 2 minutes of continuous use of the application by the user.
A proof of attention is inspired in Bitcoin's consensus mechanism Proof-of-work, where a piece of data which is difficult to produce but easy to verify. In case of the proposed proof of attention, 12 timestamps spaced 10 seconds from each other and it's respective nonces need to be calculated in order to achieve a proof of attention. Each nonce provides a correct part of the proof of attention, as long as the final hash starts with 4 leading zeros. The following algorithm present an implementation on how to calculate a valid nonce:
def calculateNonce(packageName, timestamp):
byteArray = packageName
byteArray += timestamp
hash = sha256(byteArray)
nonce = 0
while not sha256(byteArray+nonce).startwith('0000'):
nonce += 1
return nonceA proof of attention is then specified as:
| Name | Description |
|---|---|
| bidId | Campaign id to which the proof of attention refers |
| Package name | Package name of the app promoted in the campaign |
| 12 nonces | List of nonces calculated using the above mentioned algorithm |
| 12 timestamps | List of timestamps used to calculate the corresponding nonces |
When submitting a proof of attention to the blockchain additional information is sent :
| Name | Description |
|---|---|
| Wallet Name | Campaign id to which the proof of attention refers |
| AppStore Address | Appstore who will receive appstore share of the proof of attention |
| OEM Address | OEM who will receive OEM share of the proof of attention |
| Country Code | Country from which the proof-of-attention was submitted |
A proof of attention submission can be done through registerPoA function of the advertisement contract.
function registerPoA ( string packageName, bytes32 bidId, uint64[] timestampList, uint64[] nonces, address appstore, address oem, string walletName, bytes2 countryCode)
Once the smart contract verifies the validity of the proof of attention, the amount of AppCoins defined for each installation will be transferred. When an error occurs validating the submitted proof of attention, the user will not be rewarded. The following events can be emitted by the smart contract as result of processing a proof of attention:
| Event Type | Message | Sumbmission Result |
|---|---|---|
| PoARegistered | bid , PackageName, 12 timestatmps, 12 nonces, walletName, countryCode | ✔️ |
| Error | "registerPoA", "Registering a Proof of attention to a invalid campaign" | ❌ |
| Error | "registerPoA", "Proof-of-attention should have exactly 12 proofs" | ❌ |
| Error | "registerPoA", "Nounce list and timestamp list must have same length" | ❌ |
| Error | "registerPoA", "Timestamps should be spaced exactly 10 secounds" | ❌ |
| Error | "registerPoA", "Incorrect nounces for submited proof of attention" | ❌ |
| Error | "registerPoA", "User already registered a proof of attention for this campaign" | ❌ |
✔️ - Proof of attention accepted
❌ - Proof of attention rejected