Profile collections and profiles

A profile collection is where inbound events become per-customer state. A collection subscribes to event streams, resolves each event to a customer, and maintains a real-time profile for that customer: a set of attributes, keyed by a profile ID, that you can read back at request time. Profile collections and their profiles are the read side of the real-time pipeline–the audiences you build with real-time segments and act on with real-time journeys all read from them.

Unified customer profiles are your brand’s pathway to creating better interactions with your customers. Use tables from your customer 360 database to define collections of profiles, and then use those collections as the foundation for real-time interactions with your customers.

Profiles page

Use the Profiles page to manage profile collections.

• Create and manage profile collections

• Associate profile collections with event streams

• Define real-time segments, and then use them in journeys to activate individual customer profiles

• Use the Real-time API to look up customer profiles for programmatic real-time workflows

Event streams

Use the Streaming API to send events to Amperity, such as from your brand’s website, email service provider, loyalty program, or SMS service provider. Make event streams available to profiles to build real-time use cases.

Profile collections

Each profile collection can define the following types of attributes:

• Known profile attributes from database tables, such as physical addresses, email addresses, customer names, phone numbers, and transaction history

• Aggregated events data. Use functions–average, count, count distinct, distinct, max, min, most frequent, and sum–for specific event types, conditions, and timeframes.

• Computed attributes using Spark SQL expressions.

Always-on segments

Build always-on segments, and then use them in journeys to build real-life customer experiences.

Profile collections

A profile collection is defined by:

• A name and title that identify the collection.

• An identity graph, which is optional. A collection bound to a Stitch identity graph resolves customers against it, which is what lets an inbound event’s identifier map to a stitched customer.

• A set of subscribed event streams. The events on these streams are what update the collection’s profiles.

• A set of linking keys, in priority order, that the collection uses to resolve an inbound event to a profile.

• A set of attribute definitions that every profile in the collection carries.

Real-time profiles

A real-time profile is the per-customer record a collection maintains. Each profile belongs to a tenant and a collection, is identified by its profile ID, and holds:

• The profile’s attributes–the database, event, and computed attribute values the collection defines.

• The profile’s keychain–the linking-key values that resolve to this profile.

As events arrive on the collection’s subscribed streams, Amperity updates the matching profile’s attributes in place, so a read of the profile reflects the customer’s most recent recognized activity.

Profile ID

Every real-time profile is keyed by a profile ID. The profile ID is the Amperity ID–the stitched identifier that represents all of the records Amperity has resolved to a single customer. Because a collection keys profiles by the Amperity ID, each profile corresponds to one stitched customer, and the identifiers a customer is known by all resolve to that one profile.

Keychain and identity ordering

A collection’s linking keys form a keychain: the key identifiers, in priority order, that map an inbound identifier to a profile. When Amperity resolves an event, it checks every key and uses the priority order to choose when the keys point to more than one profile; a lookup through the Real-time API tries the keys in priority order and returns the first profile that matches. See Identity recognition. A keychain entry maps a linking-key value to a single Amperity ID; a value that would map to more than one Amperity ID is left out of the keychain rather than resolved ambiguously.

The keychain here is the collection-side view: the ordered keys a collection resolves against. How the keychain is built from Stitch outputs, and how an inbound event is recognized as a stitched customer end to end, is covered in real-time identity recognition.

Attributes

A collection defines the attributes its profiles carry. There are three kinds of attribute:

• Database attributes bring in values from a table in the collection’s database that has an amperity_id column, such as a customer’s name, best email address, or lifetime order count. The collection is bound to one database when it is created. When Automatically refresh profiles after each database run? is selected, database attributes update after each run of that database.

• Event attributes summarize a profile’s events–a count, a sum, a maximum, the most recent value, and so on–over an hourly, daily, or weekly window, or over all time. Each event attribute declares a scope that determines which events it summarizes: a specific event type, every event on a stream, or all of the profile’s events.

• Computed attributes derive a value from a profile’s other attributes using an expression. A computed attribute that uses timestamp_in_last, timestamp_in_next, date_in_last, or date_in_next is recalculated shortly after its result changes–for example, when a cart’s last update becomes older than 30 minutes–so its value changes even when no new event arrives. Other functions, including timestamp_diff, are evaluated only when the profile changes.

Event and computed attributes are written in Amperity’s expression language, where the full set of functions–including the array functions used to work with event collections–is documented.

Inspect a profile

To see what Amperity knows about a customer in real time, look up their profile by one of its identifiers–a linking-key value such as an email address. The lookup resolves the identifier through the collection’s keychain to a profile and returns that profile’s attributes and keychain.

A lookup behaves differently depending on whether the profile exists:

• If the identifier does not resolve to a profile, the lookup returns nothing–the profile is absent.

• If it resolves, the profile returns its full set of collection-defined attributes. Attributes that have not yet computed a value are filled with their defaults, so such an attribute reads as an empty or default value rather than being absent.

A profile’s real-time segment memberships, and a collection’s stats and history, are available through their own reads. Look up profiles programmatically through the Real-time API or Amperity’s MCP tools.