Anonymous Events

One common challenge when configuring telemetry for both websites and games are situations where you want to trigger an event but the user's identity is not yet known. This may happen in cases where you have a delayed registration process in your game or situations where a user can take some actions while signed out and then later signs into their account.

Gamesight supports sending Anonymous Events in these scenarios to let you measure and attribute these events. You can later enrich these historical events with Late ID Binding if in the future additional details about the user become available after they login or register.

Here are some potential use cases for Anonymous Events:

• 📣 Marketing Page Interactions - It is very common to want to measure top of funnel interactions such as clicks out to storefront or newsletter signups for use as an early optimization signal on campaigns. Although some of these users may already be signed in to an account, most will be anonymous to start. In this flow you can begin measuring interactions with the Web SDK anonymously. In the future if the user signs in or registers for an account this user session can be attached to that user ID with Late ID Binding.
• 🕗 Delayed Registration - If your in-game signup flow allows users to begin playing or using a game launcher without an account you may want to measure early engagement against the play session and then later once the user creates an account you can associate those events to the user.
• 🔗 Blockchain Transactions - On-chain transactions have a unique characteristic of having a strong wallet ID attached, but no additional information about the end-user provided. It is common for Web3 games to have an account linking process to join their in-game accounts to one or more wallets to allow the assets from that wallet to be used in-game. In these flows, you can use a combination of Anonymous Server Side Events to record all of your relevant on-chain interactions for reporting, and then when a user links their wallet to their account Late ID Binding will let you attribute both the account linking event and all of their on-chain interactions to give you a complete picture.

Web Events

When utilizing the Web Measurement SDK all events will associated with an anonymous session ID value by default. The Web SDK will handle all of the management of the session value and passing relevant data along with each event payload automatically.

Server-side Events

When tracking anonymous events from your server you will need to still attach some details to the event if you would like Gamesight to be able to associate this event with another user at some point in the future. You need to provide at least one of gsid, external ID, or user ID with each event although you may also pass multiple if they are available.

External ID

Passing an anonymous event with only an external ID is most common if you have an event that is attached to a partner or ecosystem ID that you expect at some point to be linked to your primary account ID. This may be something like a social ID, wallet ID, or platform specific identifier like steam ID.

Session ID

Session ID is the most common identifier to attach if you are using server-side events to measure web interactions. This allows you to trigger events from either the Web SDK or your server (or both) seamlessly. To retrieve the gsid for a user you can use the get method in the Web SDK.

gsght('get', 'gsid') // 513f5c447d384684a11603cae3083895

Making calls

• When making a call to the /events API as long as you have provided at least one external ID value or a gsid value then you can omit the user_id field.
• When you send an anonymous event, Gamesight will attempt to lookup any previously associated user ID values with the gsid or external ID values provided and automatically attach that user_id value to your event. This automated identity resolution enables you to utilize the identity associations in your device graph to improve your data quality in real-time.
• The attribution methodologies that will be applied against your anonymous event may change depending on the identifiers on your event. You can read more about the various Available Attribution Methods to learn more about how the details provided will be used for attribution.
• It is possible to send events without any identifiers that would enable attribution if in the future you intend to use Late ID Binding to reattribute the event with additional details. Unattributed events will still show in reporting and on the behavior pages to understand user behavior.

Late ID Binding

When a new user_id value is associated with an existing gsid or external ID, we will automatically lookup any existing events associated with any of these IDs and trigger a Late ID Binding. In this process we update all of the existing records for these events to include the newly associated user ID. Additionally, we reprocess attribution for these events utilizing the new user-linked data available to ensure that you get the most accurate picture of your user interactions possible leveraging the full ability of your company's first-party data.

The best way to understand the power of Late ID Binding is by looking at a concrete example of how it applies in practice.

Account Creation Example

The most common usage of Late ID Binding is updating reports after a user identifies their play session by signing in to an account.

• Marketing touchpoint - A player sees and engages with one of your campaigns and is driven to your landing page
  • This touchpoint is recorded in reporting as usual
• Trailer watch - The signed out user then watches your trailer on your marketing site
  • This triggers a Trailer Watch Goal in your reporting, associated with a anonymous gsid value
  • This interaction is attributed to the previous marketing touchpoint based on the session match
• Account registration - The user then creates an account on the same session
  • This triggers a Registration Goal and associates a new user_id with the existing session
  • The Trailer watch event will be reprocessed, replacing the anonymous user_id value with the newly registered account
  • If there are any additional touchpoints associated in the device graph with the new registered account, these will be used when reattributing the Trailer watch event

External Marketplace Example

Imagine you have a game with an external marketplace where users can buy and sell assets to be used in-game. Users can then later link their marketplace account to their primary in-game account to use those assets. With Late ID Binding the following user flow is supported:

• Marketing touchpoint - A player sees and engages with one of your campaigns and is driven to your landing page, discussing the third party marketplace
  • This touchpoint is recorded in reporting as usual
• Marketplace purchase - The user then navigates to the third party marketplace and makes a purchase
  • This purchase is reported with the marketplace user ID and item purchased. You forward this data as an anonymous server-side event so you can monitor marketplace sales in your Gamesight reports
  • Since this marketplace user ID isn't associated with an in-game user we do not have any additional identifiers that would enable attribution at this point. This event is reported unattributed so you can see the associated revenue in Gamesight
• Account register - The user then creates an in-game account
  • This triggers a Registration goal which is attributed to the marketing touchpoint based on the associated identifiers
• Account link - To use their marketplace purchases, the user then links their in-game account to their marketplace account
  • This association triggers Late ID Binding and the previous marketplace purchase events are reprocessed replacing the anonymous user_id with the newly registered account
  • Since the event is now associated with the in-game account when it is reattributed it will be attributed to the marketing touchpoint to complete the missing link in that user flow.