This article explains the primary entities you need to understand when integrating Talon.One, and how they relate to each other. If you have already covered the Talon.One Basics, after reading this article your next stop should be our Integration Guides or the API Reference.
When integrating Talon.One, data is fed into the platform from one or more Applications. An application could be an e-commerce site, a mobile app, or some other source of customer actions. The application is the owner of the API key used to send integration data.
You may have multiple applications within one account, e.g. staging and production, or different international markets. When deciding how to divide your data among multiple applications, the main consideration is whether you want to share customer activity and campaigns. It's not possible to share customer activity and campaigns across different applications.
A Customer Profile is Talon.One's internal representation of your customer. Profiles combine data supplied by your applications (e.g., attributes such as names, email addresses) with profile data that is created and updated by campaign rules (e.g., loyalty scores, lifetime expenditure, shipping address).
The unique ID for a customer profile is determined by your application. It may be an arbitrary string, but should be something that you can use to reference a logged in user. For example, email addresses do not make good profile ID's if your customers can change their registered email. A further consideration when using multiple applications is whether a given customer is "the same" in different applications. In general, we strongly recommend giving profile ID's a per-application prefix to avoid confusion and conflicting updates from different applications.
In addition to standard built-in attributes, customer profiles can be extended with custom attributes to suit your particular domain. A common use case would be internal scores or counters, such as the number of support tickets a particular customer has opened. More details can be found in our best practices guide to custom attributes.
For a full list of the built-in attributes that may be used for customer profiles, please refer to our API documentation
A Customer Session is a finite container of customer activity within an application. Most commonly, a customer session corresponds to a single order or billing cycle and will have multiple updates before being finalized. Once a session is finalized no further updates can be made, except to cancel a previously closed session (e.g. if payment failed).
Much like customer profiles, the unique identifier of a customer session is completely controlled by your integration. Any arbitrary string may be used, but it should be something that remains stable until the activity is finished. Examples of good session ID's are order numbers, or combinations of profile ID and session start time.
A customer session can contain a variety of standard attributes, such as a shipping address or list of shopping cart items. You may also associate custom attributes with a session, such as a region code derived from a customer billing address.
For a full list of the built-in attributes that may be set on a customer session, refer to our API documentation.
Each customer session contains one event or more: single occurrences of various customer actions. For example, updating the session directly records a "talon_session_updated" event. These built-in events are recorded implicitly whenever new data is received via the Integration API.
Talon.One also allows you to define completely new custom events for activities specific to your business. For example, you might wish to provide an incentive to customers who have viewed a specific product. You could then define a "viewed_product" event that can be sent to your backend, and add conditions in your campaigns so that only customers who have viewed certain products qualify.
For a full list of the attributes that may be added to a custom event, refer to our API documentation.
Campaigns, Rulesets and Coupons
Campaigns are the core entity marketers work with in Talon.One. Each campaign is made up of a name and a Ruleset that defines actions that should be taken when certain conditions are met. These conditions may refer to contextual data about the current customer, including their current session and past activity, and can be combined with boolean operators to create more complicated criteria. The actions that can be taken include setting discounts, updating profiles, sending HTTP requests and more.
Each campaign may also define a pool of Coupons. These coupons act like tickets: they have an associated code and usage limit, and campaigns can react when one of their coupon codes is included in a customer sessions "coupon" attribute. Coupons may also have arbitrary custom attributes associated with them, such as the ID of a particular customer for a personalized coupon code, or a region code for coupons that are only valid in certain areas. It's important to understand that the enforcement of these constraints is the responsibility of the ruleset and not the coupon.
While campaigns, rulesets, and coupons are most commonly created manually in our Campaign Manager application, it is also possible to create and manage them programmatically via the Management API. See our API documentation for more details.