Skip to main content

Customer data model

Atomic automatically creates and maintains customer profile records when it first sees a new customer. Atomic also collects and stores analytics event data as customers are engaged via Atomic.

  • You can enrich these profiles with external data via the Atomic API, manually via the Workbench, or via the Atomic SDKs installed in you apps.
  • Customer profile data can be used to build dynamic segments, personalize action cards and push notifications, and be used to individually tailor most action flow steps.
  • You remain in control of this data, how and where it is used, and Atomic operates as a processor of this data on your behalf under the terms of consent you have established with your customers.

Customer profile data​

Information about your customer, including metadata.

  • A profile is automatically created when Atomic first sees a trigger event targeting a user ID, a request to add or update a record via the API, or when the Atomic SDKs are initialized in your apps for a user and call the Atomic platform to start a session and request card streams.
  • Each profile contains information like user ID and metadata for example when the profile was created, when the customer was first and last seen and more.
  • Tags can be applied to customer records, as a simple way to capture simple metadata against a profile that can later be filtered on or used when building segments

Extending customer profiles with custom fields​

It is very common to sync and store customer profile data that comes from external systems, so that it can be used within Atomic.

  • The custom fields article explains how to create these fields.
  • The customer data importer tool provides a simple way to bulk-load customer data manually
  • The Users API provides an a way to sync and manage data from connected systems

Analytics event data​

Analytics events that track what the Atomic platform, SDKs, or customers have done.

  • Analytics are collected and stored for you to extract or subscribe to in your external systems
  • Metadata about analytics (e.g. first or last time they occurred) can be used when building segments

Extending analytics by sending custom events to Atomic from external systems​

  • Events from outside Atomic, such as app analytics, or business events can be sent to Atomic via API or SDK as custom events, which are then also available alongside Atomic-tracked events

Using customer data​

Sending data via event triggers, vs. syncing to customer profiles​

It is important to understand that Atomic can be used without storing extensive customer profile data.

A common pattern, especially for transactional or high-frequency use cases, is to send trigger events to Atomic to start Action Flows, and provide data to use for personalizing cards and notifications within the event payload as variables.

When sending variables in the event trigger requests, Atomic will extract the values and use them to replace any variables configured in your Action Flows, but it will not store those values as a permanent part of the customer profile. This enables you to leverage the full power of Atomic's personalization, without syncing profile data head of time. This also is how our integrations with 3rd party platforms like Salesforce Marketing Cloud and Adobe Marketo work.

On the other hand, sending common profile values over and over can be inefficient. In cases where a customer profile field will be reused multiple times, or be used in segments, it can be much more effective to store that data in Atomic profile fields.

Variables​

When an Action Flow will use variable data sent as part of the Trigger event payload, a variable must also be defined within the Action Flow (variables are listed in the left-side menu). Each variable can be fine-tuned to behave as expected, including disallowing the default value being overwritten with data from the incoming event, if required. Typically a variable would be configured with a default/fallback value, and allow this to be overwritten with event data.

Variables are resolved when the flow starts​

When an Action Flow is started, the values for the variables within the flow are resolved. This means Atomic decides what the final value for the variable will be, then this is set for the remainder of the flow. One exception is script-type variables, which will periodically re-run.

Runtime variables​

One option when configuring a variable is to allow the value to be updated at runtime, in your app. This is for situations where the final value of a variable isn't available at the time the Action Flow starts, or cases where the variable value may need to change at the time the card is displayed in-app. When this setting is enabled, and a card from this template is received by the SDKs, the SDKs will call out to your app and ask for an updated value, if one is provided, it will be updated before the card is displayed to your user.

tip

When installing Atomic SDKs, you can configure them to not send the updated values of runtime variables back to the Atomic platform inside analytics events, if you don't want the updated values being known to the Atomic platform

Context​

Data available to Action flows (including customer profile values and incoming trigger event payloads), and data generated while Action Flows run (e.g. analytics and response data submitted in cards by customers) is known as 'context' when it is being used inside an Action Flow. Learn more about this in the context reference.

Viewing, managing and using customer data​

  • The Customers dashboard, available by selecting Customers in the sidebar menu, is where you will build segments and filter and find individual customer profiles. You can also manually trigger Action Flows to customers from here.
  • Custom profile fields and custom events can be managed in the configuration area of the Workbench
  • Customer profiles can be managed via the Users API
  • Customer profile values and variables can be used inside Action Flows by inserting context placeholders
  • Analytics events can be observed in the Analytics debugger and extracted from the Workbench or via API and Webhooks
Last updated on