Identifier types
MaestraId
MaestraId is assigned to every customer in the system and acts as the primary unique identifier. A customer always has exactly one MaestraId. When two profiles merge, all MaestraIds involved are preserved on the resulting customer profile so that history and references from external systems continue to resolve.Unique identifier
A unique identifier is set by an external system (for example, a CRM, an ecommerce platform, or a loyalty backend) and uniquely identifies a customer in that system.- The same unique identifier cannot be registered twice.
- Whether two customers carrying different unique identifiers can be merged depends on your project’s configuration.
Identifier
An identifier is similar to a unique identifier but more permissive: it allows re-registration and can transfer between customers.- History for a non-unique identifier is not preserved when it moves.
- Use this type when the external value is not guaranteed to stay with the same person (for example, a temporary loyalty card or a session key).
Mobile phone
A mobile phone is used for communications (SMS, mobile push, calls, transactional notifications).- A phone number can belong to only one customer at a single point in time.
- A phone number can move between customer profiles depending on your configuration — for example, when newer or higher-priority data overwrites older data.
- An email address can belong to only one customer at a single point in time.
- Like a phone number, an email can move between profiles based on configuration and conflict-resolution rules.
Discount card
A discount card holds the customer’s loyalty card number. It can be used both to identify a customer at checkout and to attribute offline orders to a profile.Device (Device GUID, cookie)
A device identifier tracks customer activity on websites and apps. It is typically a cookie in a browser or a generated GUID in a mobile app.- One customer can have multiple devices — for example, a laptop browser, a phone, and a tablet.
- A single device attaches to the most recent customer who authenticated on it. If a different customer logs in on the same device, the device reattaches to that customer until the original customer returns.
Mobile device
A mobile device behaves like a Device GUID and is created when a customer registers in a mobile app. It is used to deliver mobile push notifications and to attribute in-app behavior to the customer profile.Payment card hash
A payment card hash is transmitted with order data and identifies a bank card without exposing its number.- It merges customer profiles when there are no contradictions in other identifiers.
- It is never used as a standalone proof of identity for communications.
How identifiers behave during merges
Maestra continuously evaluates incoming data to decide whether two profiles describe the same person.- No conflicts: profiles merge automatically. The resulting profile inherits all identifiers, subscriptions, devices, and order history from both sides.
- Conflict on a communication identifier (email or phone): the system keeps the identifier on the profile with stronger signals (recent activity, purchases, explicit consent) and detaches it from the other profile. A note is added to the losing profile.
- Conflict on a unique identifier: merge is blocked unless your configuration allows it.
Examples
Example 1.1 — Landing page, then website registration
Pavel sees an ad for a giveaway and lands on the campaign page. He submits his emailpavel.petrov@example.com to enter.
Later, on the same browser, he registers on the main site, creates an account, and places an order. He provides his name and phone number +1 (415) 111-1122.
Outcome. Two profiles exist for a moment — one from the landing page (email + device), one from the website (name, phone, device, order). They share the same device and have no conflicting data, so Maestra merges them automatically. The unified customer profile carries the email, phone, device, name, and order history.
Example 1.2 — Shared device between spouses
Pavel’s wife Irina uses the same home browser. She browses products, registers under her own email, and completes a purchase. Outcome. The device reattaches to Irina because she is the most recent authenticated customer on that browser. Her subsequent anonymous activity is recorded under her profile. When Pavel signs in again on the same browser, the device reattaches to him.Example 1.3 — Duplicate phone on a new submission
Ivan fills out a consultation request form. He enters his emailivan@example.com and, by mistake or coincidence, the phone number +1 (415) 111-1122 — Pavel’s number.
Outcome. Maestra detects the phone conflict. Pavel has higher engagement (orders, recent activity), so priority goes to Pavel: the phone stays on Pavel’s profile. Ivan’s new profile keeps only his email and device identifier; a note about the phone conflict is added.
Example 1.4 — Order placed through the call center
Pavel calls customer support to place an order. The agent records his phone number on the order. Outcome. The daily order import matches the phone to Pavel’s existing profile. The call center order is attached to Pavel’s customer history alongside his self-service orders.Example 2 — Cross-device browsing history
Irina subscribes to email on her desktop computer at home. Later she opens a campaign on her phone and clicks a link inside the email. Outcome. The unique tracked link in the email lets Maestra recognize both the desktop and mobile browsers as belonging to Irina. Browsing history from both devices is recorded on Irina’s profile and becomes available for personalization.Example 3 — Profiles merged after a later data update
Sergey subscribes to email on his desktop. Later, on a different device, he places an order using a different email address — so two profiles exist. Sergey then logs in to his account dashboard and adds his original email to the profile. Outcome. Maestra now sees both profiles share the same email and there is no contradictory data. The profiles merge automatically; the resulting customer profile contains both devices, both emails (with the canonical one marked as primary), the order, and the email subscription.Example 4 — Phone reassignment after an import conflict
Ivan subscribes via the website and actively engages with campaigns. Later, an imported batch of customer data contains a record where the phone matches Ivan’s but the email is different. Outcome. Merge is blocked because the emails contradict each other. Maestra prioritizes Ivan’s active engagement: Ivan keeps all of his data, including the phone. The imported customer is created without that phone, and a note about the conflict is added to the imported profile.Example 5 — Device-based consolidation across days
Ivan visits the site from a single browser over two days. On day one he subscribes to web push notifications. On day two, on the same browser, he subscribes to email. Outcome. A single customer profile is created. It contains the device identifier and both subscriptions. No manual merge is needed — the shared device is enough to keep activity on one profile.Privacy and data handling
Customer identifiers are personal data under most privacy regimes (GDPR, CCPA, and similar). When designing how identifiers flow into Maestra:- Collect only the identifiers you need for the channels you actually use.
- Honor opt-out and deletion requests across every identifier on the profile, not just the one the request came in on.
- Treat the payment card hash as sensitive — never expose it in customer-facing surfaces or analytics exports.
If you are unsure which identifier types your project should treat as unique versus reassignable, review your merge configuration before importing customer data in bulk. Misconfigured uniqueness rules are the most common cause of unexpected merges.