Connect customer identity without losing permission context

How should retailers connect customer identities and consent across channels?

Connect records through verified identifiers and retain the evidence behind each link. Store permissions separately by person, channel, purpose and time, then check the applicable current state before activation. A matched customer record does not grant marketing permission. Ambiguous identities, shared contact details and conflicting preferences should trigger a controlled review or suppression rather than an automatic merge and send.

Treat identity and permission as different questions

A retailer may recognise the same shopper in a store, on its website and in a service conversation. That does not mean every piece of information should be combined for every purpose. Identity asks which records refer to the same entity. Permission asks what the organisation may do with the information in a particular context. Keep those decisions distinct in the operating model.

Start with a narrowly useful objective, such as preventing a repeat buyer from receiving a first-purchase offer. Specify the source records needed and the permitted use being evaluated. A receipt contact, a loyalty account and a newsletter subscription can describe overlapping relationships without carrying identical communication preferences.

Build a record of why identities were connected

Use an internal customer key with a mapping to each source-system identifier. Preserve the original IDs and the evidence for the connection. A verified account link is stronger than a similar name. A manually corrected record should retain the reviewer and reason. If a merge later proves wrong, the team needs a way to separate the records and repair affected journeys.

Google Analytics User-ID documentation describes associating business-generated identifiers across sessions and devices and warns against assigning one ID to multiple users. This is a useful technical principle, but analytics identity settings are not an enterprise customer master. Define the retail identity rules independently of any single reporting tool.

Do not use a shared household phone number as unquestionable proof of one person. Family members can shop for different categories and hold different preferences. A reassigned mobile number creates another risk. Preserve uncertainty rather than creating a detailed but incorrect customer history that then influences personalised messages.

Model permission at the level where it applies

A single marketing-allowed flag cannot represent a realistic omnichannel relationship. Record the channel, purpose, state, collection source, effective time and relevant notice or preference version. Retain the history while making the current applicable state easy to evaluate. Decide how conflicting records are handled before a campaign export is produced.

A successful identity match should not silently widen permission. Similarly, an old audience file must not override a more recent withdrawal. Set an expiry for exports and refresh applicable preferences as close to dispatch as the workflow allows. If a channel cannot consume changed preferences reliably, reduce the activation scope until that gap is addressed.

Separate website tag settings from customer preferences

Google's consent-mode guide documents default and updated tag consent states, and notes that consent mode does not itself save customer choices. The retailer therefore needs a deliberate process for maintaining and applying preferences. A technical tag configuration is one component of the overall system, not proof that every customer record is ready for marketing.

Test both directions of change. A customer may grant a channel permission after an initial refusal, or withdraw after joining a programme. Check what happens to queued messages, scheduled exports and downstream audience copies. Keep service communications and promotional communications distinguishable so a marketing preference change is not handled by an indiscriminate switch that breaks essential support.

Worked hypothetical example: count identities and eligibility correctly

Assume a retailer starts with 12,000 POS customer profiles and 8,000 online profiles, for 20,000 source records. It verifies 3,000 disjoint pairs, each consisting of one POS and one online record belonging to the same customer. Collapsing each pair removes one duplicate entity, leaving 17,000 customer entities in the working view.

There are also 400 entities with unresolved identity conflicts. They remain visible for remediation but are excluded from individual campaign activation. This leaves 16,600 unambiguous entities. Of those, 13,280 have the applicable current permission for the planned channel and purpose. The permission-eligible share of the unambiguous population is 13,280 divided by 16,600, or 80%.

It would be wrong to describe all 20,000 source profiles as reachable customers. It would also be wrong to claim a 20% opt-out rate: the other 3,320 unambiguous entities could include missing, declined or differently scoped permissions. Report those reasons separately. This example demonstrates record arithmetic only; it is not a Fundle deployment result.

Keep correction and withdrawal operational

Assign an owner for identity disputes and a separate owner for permission propagation. A customer-service agent should be able to escalate an incorrect merge without needing to understand the underlying matching model. The data team should retain enough lineage to identify which segments, recommendations and exports used the wrong connection.

Test recovery with a small set of deliberately difficult records: a shared number, a changed email, a duplicated store account and a withdrawal received after scheduling. Record expected outcomes before running the test. Mask personal details in general dashboards and limit raw contact access to the roles that need it for the approved workflow.

Identity and permission launch checklist

1. Define the entity being matched and the evidence required for a link.
2. Preserve source IDs, merge history and a reversible correction process.
3. Store channel and purpose preferences with effective timestamps.
4. Specify a conservative response to conflicts and unresolved identity.
5. Verify withdrawal propagation through queues and exported audiences.
6. Report identity coverage and contact eligibility with separate denominators.

Use Loyalty and CLM and Fundle Brain to frame a workflow review. Request a Fundle walkthrough with anonymised identity conflicts and preference changes. Confirm the identity rules, access controls and downstream update behaviour supported by the proposed configuration before using it for activation.

Questions from retail teams

Is a hashed phone number sufficient for identity resolution?

Hashing changes how an identifier is represented; it does not prove that the identifier belongs to one person or that a marketing action is permitted. Shared and reassigned numbers remain ambiguous after hashing. Use verified linkage evidence, preserve source context and evaluate the applicable permission independently before placing a customer in an activation audience.

Should a website and a store always share one customer ID?

A common internal key can be useful when the relationship between records is verified and the use is appropriate. Keep the original source IDs so the connection remains traceable. Do not force every anonymous or ambiguous interaction into that key. Some records should remain separate until the customer or another reliable process confirms the relationship.

What should happen when two linked records contain conflicting preferences?

Apply a documented rule using scope, timing and evidence rather than choosing whichever value permits contact. A recent withdrawal for the relevant channel should not disappear during a merge. Where the conflict cannot be resolved reliably, suppress the proposed activation and route the record for review. Preserve both events so the decision can be explained later.

Does consent mode store a full customer permission history?

No. Google documents consent mode as a mechanism for communicating consent states to its tags, and its guide says the mechanism does not itself save choices. The retailer needs an appropriate preference record and update process around it. That record should support the channels and purposes actually used by the business, beyond website tag behaviour.

How can teams test withdrawals without using real customer details?

Create controlled test identities with known preferences and follow them through scheduling, export and dispatch checks. Change one preference after the message is queued and verify the expected suppression. Include more than one channel so the team can confirm scope. Keep a written expected result for each case and inspect the downstream logs.

Sources and further reading

• Google Analytics: Measure activity across platforms with User-ID — Business-generated identifiers, cross-session identity and the risk of assigning the same ID to different users. Retail master-data design is original guidance.
• Google Tag Platform: Set up consent mode on websites — Default/update consent states and the explicit distinction that consent mode does not itself save choices. No legal compliance conclusion is made.