Skip to main content
  • Comparison table of implementation methods
  • Decision tree: which method to choose
  • Event types and naming conventions
  • Required vs optional parameters
  • Common implementation patterns
OneView is designed to be a flexible platform that can be used to track a wide variety of events. Depending on your use case, you may want to send events from the frontend, backend, or both. Events must always at least include: This guide will show you what types of events you should send to OneView, how to send them, and how to ensure that they are correctly matched to the same user.

​
Event Types

The event type is defined by its name. There is no limit to the name and number of events you can send to OneView. However, we recommend sending at least the following types of events:
RequiredDescriptionFrontend SourceBackend Source
Page Views✅A page_view is the event you send when someone looks at a page on your website.Yes
Conversion Event✅Events you send when your users do what you want them to do, like buying something or signing up.Yes
Identify EventEvents that you send when users are recognized, for example during login or sign up.

​
Event Sources

You can safely mix and match event sources. For example, you can send page views from your website, and conversion events from your backend.
In technical terms, events are API requests sent to OneView as a JSON object containing information about the event, and can be sent from different sources:
  • From your Frontend: You can use Google Tag Manager® or Google® gtag.js.
  • From your Backend: You can use Server-side Tag Manager® or APIs.

​
User Identifiers

Identifiers are unique values that help OneView match events to the same user. They are used to build the Identity Graph that connects a user’s actions across devices and platforms.

​
FAQ

Make sure you are sending at least one event where both identifiers are present.If you work in or cannot send page_view events from your webapp, then you need to send Identify Events to match client_id and user_id, for example a login event.
Make sure you are not sending test events along with production events

​
Adaptive Targeting

It depends on the Media Partner, please check their documentation.
Normally there is no need to retrieve user data from your CRM, as OneView will automatically match on the Identity Graph if a previous event in the journey (e.g.: login) sent them already.
You can use Workflow Automation tools to extract and hash user identifiers (e.g. from your CRM or database) before sending them to OneView as an event on its own; for example you can call it identify.

​
Custom Domain

In general, expect less accurate results; specifically:
  • You are likely to see less traffic hitting your website (in the range of 10% - 40%), depending on your industry’s average ad-blocking usage.
  • If you are sending Conversion Events from your browser (e.g. thank you pages), you may record mismatches between actual and recorded conversions.
  • If you are sending Conversion Events from your server, you may see unexpectedly short customer journeys, and as a consequence, many incorrect Direct attributions.
If you are using multiple sudomains from which you send Frontend Events, you must repeat this process for each subdomain.