4th Jul 2019

Talon.One and BI/Reporting

Talon.One offers reporting on the data you send via our integration API, showing you basic stats such as campaign performance and customer activity over a time period.

For businesses with an existing data warehouse and BI reporting tools, it's more desirable to instead pull data from Talon.One into the same unified warehouse so that it can more easily be joined with data from other sources. Our Management API offers a number of operations to help you accomplish this synchronization.

Entities to synchronize


Every request to our Integration API results in an event being recorded. This event will contain attributes as well as information about any effects that were triggered by campaign rules in response to the event. Events are immutable once created, which means that you can safely retrieve all events sorted by time, and continuously poll for events newer than the last one received.

Customer sessions

Customer sessions group together events. They can be seen as mutable views over the immutable event data. As such, it's recommended that you only sync sessions after you have received events belonging to that session.

Customer profiles

Events (and by extension, sessions) may belong to a customer profile. Profiles are always mutable, and contain aggregate values such as TotalSales which keeps a running tally of the Session.Total property for all closed sessions.

Synchronization algorithm

The general algorithm for keeping an up-to-date copy of Talon.One data in your data warehouse is:

  1. Initialize a lastSync variable with the value of the created timestamp of the last event you already have stored. If no events have been stored, set the created timestamp of your application.
  2. Initialize profilesToFetch and sessionsToFetch variables as empty sets.
  3. Request all events created after your last sync using the getApplicationEvents API operation. This operation accepts a createdAfter query parameter that should be set to the same value as lastSync. The response will contain an integer totalResultSize property and a data array containing events.
  4. For each event in response.data:
    1. Store a new talon_one_event record in your data warehouse
    2. If event.sessionId is non-zero, add it to the sessionsToFetch set.
    3. If event.profileId is non-zero, add it to the profilesToFetch set.
    4. Set lastSync to event.created.
  5. If response.totalResultSize is equal to the number of items in response.data:
    1. For each ID in profilesToFetch:
      1. Fetch the profile using the getApplicationProfile API operation.
      2. Store a timestamped talon_one_profile_snapshot record in your data warehouse.
    2. For each ID in sessionsToFetch:
      1. Fetch the session using the getApplicationSession API operation.
      2. Store a timestamped talon_one_session_snapshot record in your data warehouse.
    3. Sleep for 1-5 minutes.
  6. Repeat from step 3.

This above process can be run continuously, and the sleep interval can be tuned to balance between the number of API requests performed and the latency of updates to your data warehouse.

Normalizing event data

Depending on the sophistication of your existing BI tools, it may be desirable to "renormalize" the nested event/effect data at step 4.1. For further reference on the structure of events and how to interpret the event.effects array, see Handling Effects in the Integration API documentation.

Still need help? Get in touch!
Last updated on 4th Jul 2019

Was this article helpful?

Thank you! You have already voted
