User Acquisition: UA Extended
A user acquisition mechanism relying solely on the blockchain, as proposed by the base implementation of the AppCoins Protocol, provides extreme transparency and a solution with no need for third-parties to manage and process user acquisition campaigns. However, this approach requires the user to support network fees when submitting a proof of attention. Furthermore, depending on the gas price provided by the user, when submitting the proof of attention, this process may require some time in order for the transaction to be processed by the network. Thus, an extension to the AppCoins Protocol is provided, depending on a third-party to validate and submit the proof of attention.
Below is a diagram showing the different artefacts that compose the User Acquisition use case through a third-party and 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 Extended use case are:
- Third-party SDK
- Third-party Wallet
- AppCoins token smart contract (Mainnet & Ropsten)
- User Acquisition Extended smart contract
A developer interested in promoting his application through the User Acquisition mechanism is required to register a campaign to a certified third party how will be responsible for storing campaign's information and add the required information to the blockchain. A campaign created through the User Acquisition extension will depend on a third-party providing a web frontend to create a campaign.
In order to create a user acquisition campaign, a developer must provide the same information required for the base User Acquisition use case:
| 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) |
In addition, AppCoins Protocol extension for User Acquisition allows the developer to specify if the campaign is subject to ip validation. On the other hand, through a third-party it is possible to verify if the Poof of attention registration is coming from a country included in the campaign reliably.
An offer wall similar to the the one described for the base User Acquisition use case will be presented either by the third-party or any other interested party. As in the base User Acquisition use case, an offer wall is expected to provide, 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.
Regarding proof of attention specification, the proposed protocol extension provides additional information for each proof of attention registered. Using the proposed protocol extension for User acquisition, the proof of attention is calculated as specified in the AppCoins base protocol.
A proof of attention is specified as in the base protocol:
| 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 |
In addition, the proof of attention contains:
| 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 |
Once a proof of attention is computed, the third-party SDK is responsible to submit the proof to the third-party's back-end in order for the proof to be signed. During this step, the server side is responsible for registering the IP from which the proof of attention was submitted. In addition, the third-party verifies the country from which the proof is submitted based on the user's IP, the proof of attention is then validated through the same algorithm used for the base User Acquisition use case, as follows:
byteArray = packageName
for timestamp in timestampList:
byteArray += timestamp
firstHash = sha256(byteArray)
byteArray2 = []
for nonce in nonceList:
byteArray2 += nonce
byteArray2 += firstHash
finalHash = sha256(byteArray2)
if finalHash starts with 4 leading zeros:
return valid
else:
return invalidIn addition to verifying the proof of attention submitted, the third-party's back-end will verify if the user's address has already converted the campaign.
In case the proof of attention is incorrect, an error message should be returned by the back-end service.
| Error message | cause |
|---|---|
| Malformed proof | Wrong number of nonces or timestamps provided |
| Invalid nonce | At least one nonce is not valid |
| Campaign does not exist | Campaign id is not registered |
| Campaign is not valid | Campaign was disabled or no longer valid |
| Invalid county | Campaign is not valid for the user's country |
| Maximum daily conversions exceeded | Maximum daily conversion for a campaign in a single IP exceeded |
Considering the validation is done by the third-party's back-end, the proof of attention is signed by the third party's private key used for interacting with the Ethereum Blockchain.
ipHash = sha256(ipAddress)
txid = merkleTree(CampaingId,
advertisementAddress,
ipHash,
userAddress,
timestamps[0],nonces[0])
return sign(txid), txidBeing the ipHash the hash of the Ip submitting the proof for signing and userAddress the user's wallet address submitting the request. As the proof is signed, the signed proof along with a transaction id is sent back to the third-party's SDK which later submits to the third party's Wallet.
The third-party's Wallet is then responsible to submit the signed proof of attention to a third-party's back-end on which the proof is sent to the blockchain in order to provide the campaign funds to the user. The third-party will then execute:
checkSignature(sign(txid), txid)
if not alreadySubmitted(txid):
addToBulkList(txid);Through this method, a third-party is able to submit signed proofs of attention in bulk, by making a merkle tree of the batch of transactions, at a frequency defined by the third-party. Once a certified third-party submits signed proofs of attention to the blockchain, the smart contract validates the sender is whitelisted. In order to submit a bulk proof of attention, the third-party is required to call registerBulkPoA function on the Extended Advertisement contract.
As the submitted signatures are validated in the smart contract, the reward for each proof of attention is provided to the third-party, which will latter provide the reward to the user internally. Thus a user will be able to spend the reward for proofs of attention submitted through this method in the third-party's partner applications.
Considering a campaign created based on the extended user acquisition use case suggested, we will go over each step taken and how the user will be rewarded. Let's imagine Trivial Drive developer has a campaign created through a third-party.
| Transaction | User | Developer | Store | OEM | Advertising Contract | Third-party | Third-party (Fee) | User (Third-party) | Developer (Third-party) | Store (Third-party) | OEM (Third-party) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Campaign Creation | 30 | -30 | 1.2 | -31.2 | |||||||
| Signed PoA 1 | 8.5 | 1.0 | 0.5 | ||||||||
| Signed PoA 2 | 8.5 | ||||||||||
| Bulk submission PoA 1 | -10 | 10 | |||||||||
| Bulk submission PoA 2 | 1.0 | 0.5 | -10 | 8.5 | |||||||
| In App Purchase (extended) | -5 | 4.25 | 0.5 | 0.25 |
As the developer creates a campaign through the third-party, fees may apply, as in the table a 4% fee is applied by the third-party. The Appcoins are then transferred to the extended advertisement smart contract, in this case 30 AppCoins. Now two possible scenarios may arise as not all Stores and OEM's may be registered in the third-party's service, thus we present PoA 1 and PoA 2 use cases.
In case a user submits a signed PoA to the third-party's back-end, given both the Store and OEM are registered in the third-party's service, the AppCoins are off-chain transferred to the respective parties as shown in the above table. However, the reward is only transferred to the third-party's wallet once a bulk submission is made by the third-party (Bulk submission PoA 1). The upfront transfer of off-chain funds before bulk submitting the proofs, as presented in Signed PoA 1 row, is up to the third-party.
Given a Store or OEM is not registered in the third-party's service, user acquisition rewards (OEM/ Store shares) are directly transferred to OEM or Store Ethereum address. This use case is presented as Signed PoA 2 and Bulk submission PoA 2. On the other hand, the OEM and Store, not registered in third-party's service, will only receive their user acquisition rewards once the third-party bulk submits the PoA's.
Regarding in app purchases, this extension enables for complete off-chain in app purchases if all the parties are registered in third-party's service. This allows for less transaction costs and faster transactions between parties.