Key GDP Features

Some of the relevant terms used in this section of our GDP technical documentation are listed below with brief definitions.

• Identities: GDP's service for unifying guest identifiers and interactions.
• Identifiers: Individual attributes describing a guest such as user ID, email, and phone.
• olo_identity_id: Unique system identifier mapped to guest profile.
• Computed Properties: Advanced calculations performed utilizing Track events.

Further segmentation, analysis, and personalized guest engagement is driven by two key features within GDP: Identities and Computed Properties. Through Identities, multiple Identifiers for a single guest can be resolved to unify a guest profile. Computed Properties allow for greater customization and analysis of Track event data submitted to GDP.

Identities

Various Identifiers for any individual guest can be sent through GDP via Identify events. Identifiers can be a single property or collection of properties used to identify a guest across various sources. Common examples include email, phone number, payment token, and cookie ID. 

For each unique Identifier passed into GDP as part of an Identify event or Track event, a new olo_identity_id is created. Because of this, multiple guest profiles can exist simultaneously for a single guest within Olo GDP. The Identities feature aims to resolve the various Identities that may exist, matching them into a single guest profile.

Identities - Resolving a Guest Profile

Diagram 2: The Identities service will recognize that three individual records are to be combined into a single guest profile. These separate brand interactions are now linked to one guest profile through the common Identifier, Credit Card Token.

Priority

GDP prioritizes identity resolution through the analysis of Identifiers. Default GDP Identifiers include uuid, email, and phone number. The Identities service is configured to interpret uuid as the highest priority Identifier, followed by email and phone number (detailed in Diagram 3 here). In a scenario where multiple Identify and Track events exist for a guest, this built-in prioritization logic determines how these data points are consolidated. Additionally, if a guest has multiple values stored for a single identifier (e.g. multiple email addresses), the system uses alphabetical order to determine which is the higher priority for that guest.

Identifier Priority Order (Default):

1. uuid
2. email
3. phone

In Diagram 2, the Identities logic analyzes default priority order, unifying to a single guest profile. In this example, each olo_identity_id contains different sets of Identifiers. GDP prioritizes the olo_identity_id containing the highest priority Identifier. 

Note that priority order is customizable but the default configuration is intended to align with most customer needs in supporting the Identities feature.

Limits

Customers can configure the number of specific Identifiers to be associated with a single olo_identity_id. For example, if a brand desires to focus their guest identity around a household, guest profile limits can be configured to allow multiple phone numbers. In this case, phone numbers can then be limited to two values stored on the guest profile. If a third phone number were to be received by GDP, the oldest one would be replaced by the most recent one for that guest profile.

Identity resolution is dependent on the configuration of both Priorities and Limits to form the most accurate representation of a guest in GDP. Specifically, customization of Priorities and Limits ensures that the definition of a guest in GDP matches the internal definition of a guest for a brand.

Computed Properties

Computed Properties are custom calculations created by brands, allowing more detailed analysis of data stored as Track events in GDP. Default segmentation options are robust enough to fulfill a variety of analytical and engagement use cases, but those seeking more personalized guest communication or detailed insights into guest behavior can take advantage of the advanced capabilities offered through Computed Properties.

Benefits

Computed Properties enable any Track event to be used to create a calculation that is saved to each individual guest. For example, if a brand is attempting to gather a list of guests who have joined their Loyalty Program, default segmentation can readily accommodate. Alternatively, if a brand is seeking to understand the number of rewards redeemed in the last 30 days, Computed Properties can provide this enhanced calculation. The system will store the relevant number (in this case, rewards redeemed) as a single integer, attached to each individual guest.

Sample Computations

Potential brand use cases can include the following (note: Track events are in bold):

• Count of Order Completed events in the last 30 days
• Count of Campaign Email Clicked events in the last 6 months
• Last Reward Redeemed event date
• Average spend of Order Completed events in the last 90 days (via the Total property on the Track event)
• Average spend on Order Completed events at a specific location in the month of June, only on weekdays during lunch hours (via the Total property on the Track event as well as time of day and day of week of the event)
• Last Automation Completed event tracked for a guest
• First Survey Completed event tracked for a guest 

Configuration Details

The Computed Properties feature is accessible via the Olo Engage Dashboard, with the following pieces of data available for selection: 

• Computation Type
  • Available computations: Count, Sum, Min, Max, First Value, Last Value, Last Timestamp, First Timestamp, Average
• Track Event
  • Example Track Events: Order Completed, Segment Entered, Segment Exited, Reward Redeemed, Loyalty Program Joined
  • A list of GDP’s first-party Track events can be found in this Creating a Computed Property article
• Property
  • Example Property: Total
  • Note: If a Computation Type requires that a Property be defined in order for the calculation to be completed, you’ll be prompted by the product to select one. For example, Average calculations require a number so to get to the Average of an Order Completed event—if you’re wanting the Average on total spent—you must select the Property Total.
• Conditions
  • Detailed data points that are associated with a Track event (conditions vary by Track event)
  • Sample condition use case:
    • Computation Type: Count
    • Track event: Order Completed
    • Condition: Location + Equals + <location name>
    • Run Computation: <select date range>
• Run Computation
  • Date range required for proposed computation (e.g. Last 30 Days)

Related Learning

Additional supporting documentation, including FAQs and step-by-step instructions, can be found here in additional Computed Properties articles.

To learn How to Access GDP Data, please continue to the next article in the series here.