This feature rose from a core customer need which had never been approached by any other company in the world. This will help the product managers & growth executives of the app, analyze and answer end-user questions like:
- I referred a friend; he signed up – we did not get the credits! Why?
- My friend got the reward, but I did not. Why so?
- My friend has done 5 transactions, but I am not getting my rewards. Why?
and many such typical questions which are common occurrences when you run Growth Hacks that offer incentives to your users.
Most of these instances are of user who are angry or disgruntled, and they rarely understand that a mistake/miss on their part would have caused this. Some of these may even volunteer with negative reviews on the Play/App Store, or spread bad reputation on social media.
This feature is to help you prevent and protect from such situations.
Often the users would not receive their rewards. This happens for many reasons. It may sometimes be just one of the many reasons too. Here is an explanation on what goes behind the scenes for this feature:
This feature works as a quick fix for your User Relationship Management. Whenever some user cites such issues as have been stated at the top of this post, you would need to get two things from them.
- Friend Detail: New User’s Registered Email ID
- Referrer Detail: Referral Code used by them, or the registered email ID of the Referrer
Navigation: Dashboard >> Analytics section >> Query Resolution tab
Here you would need to enter the Referrer & Friend Details as applicable in the given fields.
Once you enter the details, Click thebutton
The results would be varied, and can be roughly classified into the following scenarios:
- Scenario: Friend & Referrer Attributed
- Scenario: Self Referral
- Scenario: Friend neither clicked on referral link nor provided referral code
- Scenario: Friend already attributed
- Scenario: Wrong referral code entered
- Scenario: User marked as an existing user
- Scenario: Referrer marked as Blocked
- Scenario: Click IP – Install IP mismatch
- Scenario: Friend marked Suspicious
- Scenario: Referrer Rewards maxed out
- Scenario: Friend registered before being invited
- Scenario: Conversion events not received
In case both the stakeholders, Friend & Referrer, have been attributed properly and all the events were successfully done – you will get a message as show below:
we will check all the below conditions. if the condition is satisfied , we display tick mark with the green circle else we cross mark with the red circle.
- Self Referrals or not
- whether friend entered referrer code/clicked on referral link or not
- User Marked as an existing user/Suspicious/Blocked or not
- Referrer has reached the maximum reward capacity or not
- Attribution was done or not
- All the conversion events successfully received or not
You shall get a list of the Rewards that have been processed for each, and the statuses against each.
The Info button (green info icon) against each of these users would give you a detailed info into each user.
When the users(friend and referrer) use same emails or same devices then we consider the referrals as self referrals.
Enter referrer email id/referral code and friend email id in the Query resolution.click on Find resolution button.Error message will be displayed as shown in below image.
Sometimes friend might already been attributed to referrer. if the friend enter referral code of another referrer or clicks on another referral link, in these cases attribution will not happen again and rewards will not be given to the new referrer.
We display a message saying “Friend is already attributed to ‘user email'”.
Sometimes users might be entering wrong referral code. in this case we will display why the user not attributed with the wrong referral code entered.
When friend is marked as an existing user then he will not be rewarded. In such case, attribution will not be done and friend is marked as an existing user.
Sometimes, as stated earlier, specific fraudulent behaviour by certain Referrers leads for them to be Blocked by the system.
This occurs primarily when a Referrer has at least 5 Friends or more, who have been tagged as Suspicious.
Often, users click on referral link in one network and install the app in another network.When such an instance takes place, the IP address recorded during the Link Click and install were different.
This leads to a IP mismatch for attribution & a solely link based Referral program would reject the attribution
New users who try to game the system may have resorted to malpractices which may include using devices with invalid Hardware IDs. In such cases their IMEI IDs are incorrect i.e. they would not have a valid IMEI checksum value.
In such instances the new user, i.e. the Friend gets marked as suspicious.
Rewards would stop flowing to the Referrer, when he has reached the maximum reward capacity i.e. the Redemption Cap for a particular campaign.This would not imply for Friend.
Often we see that users send their referral invites to a bunch of their friends, rarely knowing that some of them may have already been using the app. In such cases, the Friend may try to re-install the app using the newly obtained invite, in hope of some credits.
AppVirality makes it a point to prevent such cases from eroding your rewards, primarily because the user was originally pre-registered. The users would not be rewarded then.
When any of the conversion events were not received (events added in campaign), we will display the conversion events which are not received .
The above are a few of the many examples of how many scenarios can be clarified using this tool/feature. Another case is where the Friend may have installed the app upon getting the invite – but clicked on the referral link after the install was done. This is a clear case of attribution mismatch, and cannot be helped with. The system shall not reward either of the parties in such an instance.