Server-side tracking for iGaming industry

Accurate digital marketing attribution is the key to effective online advertising in many industries, and iGaming is not an exception.

Even though user journeys in this industry are entirely different, the challenges are still the same: 

The iGaming tracking solution lies in the correct stitching of signals from different sources, and that’s where Stape can help you. With server-side tracking and a scalable NoSQL database called Stape Store, you can preserve click IDs necessary for attribution and properly deliver them to any advertising and/or analytics platform.

Also considering the nature of the iGaming industry, where users might be using ad blockers more often compared to other verticals, Stape's Custom Loader is the perfect solution to achieve close to 100% accuracy of event tracking and is less likely to lose valuable conversions.

Let's review the typical user journey in the iGaming industry and its key conversions - they include but are not limited to sign up, first time deposit (FTD), 'big wins', etc.

Not all of these events occur on the operator's website. Some can only be triggered by third-party services, so we need to build specific logic to track these events and report them to the destinations with the proper payload.

A fair warning: you should have some level of control over either your CRM or the third-party services that manage users' deposits or payment providers. We need a system that can send us a signal when something happens, such as an increase in deposits, a win, a sign-up, etc.

Let's dig deeper into possible scenarios and potential solutions you can introduce to improve ad attribution from the different channels, particularly what events and payload you should report.

The user must have an account to proceed with playing games. As an operator, you should keep track of your users, so sign-up (login) is the very first touchpoint where you can start tracking your users who are already de-anonymized.

The easiest and most reliable way is to create a dataLayer push that will trigger the necessary tags in your web GTM container. Besides the event name, this dataLayer push should contain all the relevant information from your CRM about this user - first name, last name, email address, your internal persistent user ID, and any other information that you consider important to report to the advertising network and/or analytics (game level, deposit, etc.). *

Along with the sign-up or login event, you might consider storing necessary advertising info like click IDs and/or UTM tags in Stape's database - Stape Store. For example, use a persistent user ID and store under such a user ID all the cookies from the possible destinations - that can be FB click ID, Google Ads click ID, or any affiliate network click ID. We will be able to use it later on in lower funnel events.

It is a common practice to give new users a deposit they can spend to get acquainted with your games. Once they spend it and want to continue, it is time to top up the deposit. There are numerous ways and approaches this particular action may happen; here, we'll review one of the most straightforward ones, so you can get the idea and adjust it according to your needs or situation.

If the user shows the intention to top up their balance, they'll be redirected to the payment service provider to select the preferred payment method and complete the purchase. Once the transaction is successful, you should receive some sort of signal from the payment service provider.

Depending on the trigger you can set up, further methods may vary. Here we'll consider that the payment services provider updates the balance of the user in your CRM. Now you need to set up a webhook or automation that will send the FTD event, the user data, and any other important information, like the deposit value, to the server GTM container. You are welcome to read our detailed article: What are webhooks, webhook servers, and how to use.

Now that we know that the FTD event has happened, it is time to report to the destination with previously stored click identifiers for proper campaign attribution. Use the user ID received from the webhook, and look it up in Stape Store. In response, the Stape Store Lookup variable returns, you'll find all previously stored information like click ID values.

Now you can report the FTD event to the necessary destination. For example, the majority of affiliate networks require only several parameters, like value, currency, and click ID. This click ID is the essential parameter to attribute this conversion back to the advertising campaign, which, in the end, is our goal. Thus, you'll have accurate information on which campaign performs well and which does not, so you can make informed data-driven decisions on how to allocate your marketing budget.

At the same time, you should write to Stape Store a new parameter for this particular user - something like ftd: true, so the next time when the balance is topped up, you know that it's something else, that the FTD has already happened, and apply a different logic when firing your events for building audiences. You may keep track of the second, third, and all the further balance changes if you need to, if that somehow affects your marketing decisions. Feel free to store any additional data that, in the future, might help you decide which campaigns will suit a user who performed specific actions.

This event can be called differently for each operator, but the idea is the same - the user has won the game, and you can assign them to a specific audience to start running different kinds of campaigns.

The deposit amount that defines a significant win is up to an individual operator, but the idea is the same - whenever the balance is increased, another webhook/automation is triggered that reports this event to sGTM. You apply the same logic, looking up for click IDs in Stape Store and reporting this conversion to all required destinations. But in this case, you need to differentiate whether the balance was topped up via the payment service provider or via the game itself (the "win").

You should apply different logic while building the webhook or automation, while the logic on sGTM remains the same. You can also keep track of the number of wins in Stape Store and report different conversions depending on the information stored. This is what you control and define, and what allows you to be highly flexible when reporting different kinds of conversions, to improve your marketing efforts and have accurate data in your advertising/analytics platforms for the best possible data-driven decisions.

Server-side for the iGaming industry has lots of potential to unlock previously missed conversions due to missing attribution data.

Please feel free to reach out to us, and we'll be happy to find the most effective way server-side can benefit in your particular case.