MyTracker SDK collects stats on each app user
and generates the base needed to build recommendations.
Connect SDK to the app that the user will interact with.
For details, refer to sections iOS,
Android,
Unity.
Ensure you configure the purchase tracking and payment verification.
For details,
refer to the Purchase tracking section.
Choose a user identification method:
If your application requires registration,
and each user has a unique identifier,
then configure user tracking with the parameter customUserId
(see sections for iOS,
Android,
Unity).
customUserId
should not change since the first launch of the application
If your application does not require registration
or users do not have a unique identifier right after the first launch,
you should use instanceId
(see sections for iOS,
Android,
Unity)
and pass instanceId in the customUserId parameter.
instanceId identifies the physical device
but not the user, so the recommendation for the same user
may be different on different platforms
According to the instructions for events with a custom name
(for iOS,
Android,
Unity),
set the following events to be sent:
Offer trigger offer_trigger
Purchase of offer purchase_offer
Opening/closing an offer card offer_card
User account status account_status
All events should be sent from the device (not the server).
To not accumulate events in the buffer,
we recommend specifying the flush parameter
when you send events (see instruction for the force sending events for
iOS,
Android,
Unity).
All event parameters should be passed as a string;
the decimal separator for real numbers should be a point.
Events details are given below.
Offer trigger
You should send the offer_trigger
event when a user falls under or drops out
of the offer display condition
(for example, start/end of the promotion in the app).
Event parameters should be passed as a string:
Name
Description
Example
action*
"start" if a user falls under the offer display condition
"end" if a user drops out of condition
"start"
placement_id*
Offer placement identifier
"A"
sku**
Name of the bundle in the store
(it may not be unique for the store item)
"com.app.10dollars"
payload**
Unique item name within the application
"offer.for.unpaid"
timestamp*
Event timestamp (UTC+3 in seconds)
"1597316958"
* — required parameter.
** — required parameter for the item recommendation and optional for the set recommendation.
You should send the account_status
at least every time the application is launched.
The table below shows general parameters
that can characterize the account status.
Try to find an analog in your application
for the maximum number of parameters listed.
To add more parameters, contact our support team.
Event parameters should be passed as a string:
Name
Description
Example
in_game_currency_<name>
Any balances of in-game resources, where name is a resource name
"444"
in_game_currency_diamonds
Any balances of in-game resources, such as diamonds
Set the percentage of users to include as control and test groups.
For example, you can show the default price for 30% of players
and a personalized offer for 70% of players
in the Players 10 level segment.
Determine the default offer (item or set)
to include in the control group.
Set the placement identifiers
where the offers will be run.
Each test should have its own placement_id.
Determine the features of the recommendation:
How often we can change the offer price.
What is the frequency and duration of recommendations?
For example, on a timer, on weekends every week, etc.
3. Integrate Personalize API
Integrate Personalize API to send real-time recommendation
requests to the MyTracker server and display personalized offers in the app.
Check the queries:
You should send a request from different platforms
(iOS, Android, Unity, Flutter) separately,
each with its sdk_key.
To get sdk_key,
embedded SDK to your app.
Choose one of the options for sending requests:
From mobile app.
In this case, you should better use
an asynchronous request for recommendations
immediately after loading the application.
From mobile app backend.
We recommend you do not send requests
until the user has accessed the offers
so that MyTracker has time to gather as much data
as possible.
Repeated requests should be made at least once a day.
Consider the following options:
Caching the latest recommendations on the client-side.
You will be able to give the most current recommendation to the user,
even if there is a problem with the network,
a delay in getting a recommendation, or an error on the server-side.
Asynchronous request sending.
Using reset parameter in API requests (optionally).
If reset=True, the service gives the user the most recent recommendation
(offer price may change).
If reset=False, the service returns the last recommendation
(the offer price will remain the same).
After you connect MyTracker Personalize,
app users will receive personalized offers.
Depending on the conditions you set,
recommended prices may be displayed as a discount or as the default price:
You will receive automatic reports on the results of the A/B test
and information about profits from personal recommendations by email,
Telegram channel, or any other way convenient for you.