Tag: Bot Detection

Your CRM has identified an apparent ideal customer. This person opens almost every email, checks products repeatedly, moves between devices, and redeems offers with remarkable timing. The activity is real enough to enter your dashboards, but it may not belong to one person or represent the intent your models assign to it.

Before you increase bids, trigger a high-value nurture sequence, or extend another promotion, you need to know whether you are acting on a coherent customer or a marketing data doppelganger. The practical fix is not another round of duplicate removal. It is an identity-confidence system that separates observed activity from actor, intent, and customer identity.

What your apparently complete customer profile may be hiding

A marketing data doppelganger is a customer profile that looks internally valid but does not map cleanly to one actor. Its email may be deliverable. Its clicks may have occurred. Its purchases may be legitimate. The error appears when your systems treat all those events as evidence about the same individual.

This problem has two main identity patterns:

• Convergence: Multiple people or systems are folded into one profile. A shared login, forwarded corporate alias, recycled email address, AI assistant, and human account holder can all contribute activity that appears to come from one customer.
• Fragmentation: One customer is distributed across multiple profiles. Alternate email addresses, several devices, subscription accounts, loyalty records, and repeated new-customer registrations can make one person look like several unrelated prospects.

Delegated activity complicates both patterns. AI assistants can summarize emails, compare products, monitor prices, complete forms, and sometimes make purchases. That activity is not automatically fraudulent or irrelevant. It is evidence that software acted, possibly with a customer’s authorization. It is not automatically evidence that a person read a message, evaluated an offer, or developed stronger purchase intent.

Use three separate questions whenever a profile drives a decision:

• Identity: Which customer, account, household, or organization do we believe this activity belongs to?
• Actor: Was the event produced by a person, an authorized assistant, an email client, an automated workflow, a shared user, or an unknown process?
• Intent: What does the event actually establish: message delivery, monitoring, consideration, authorization, or a completed commercial outcome?

Those answers are not interchangeable. A deliverable email establishes that a destination can receive mail; it does not establish that one enduring person controls it. A completed order establishes a commercial outcome; it does not prove that the payer, shopper, recipient, and account user were the same person.

The important correction is simple: valid events do not guarantee a valid person-level interpretation. Your job is to preserve what was observed while reducing confidence in conclusions the evidence cannot support.

Audit the marketing decision before cleaning the database

A database-wide identity project can become expensive and abstract before it changes a single campaign. Start with one consequential decision: a lead score, promotion rule, churn prediction, retargeting audience, acquisition report, or budget forecast. Then work backward to the identity assumptions that make the decision possible.

1. Write the claim behind the decision. A high-engagement segment may depend on the claim that repeated opens and product views represent increasing interest from one person. A new-customer discount may depend on the claim that one profile represents one previously unseen customer. State that claim plainly.
2. List the events that support the claim. Separate email opens, clicks, page views, form submissions, account activity, promotion redemptions, and transactions. Do not collapse them into a single engagement total during the audit.
3. Recover event provenance. For each event, retain the event time, collection source, profile and account identifiers, campaign, session or device identifier where permitted, related transaction or promotion, automation marker, and downstream outcome. A missing provenance field is an audit finding, not permission to assume a human acted.
4. Classify the likely actor. Use practical states such as human-confirmed, delegated or agent-assisted, platform-generated, shared or ambiguous, and unknown. Preserve unknown as a real category. Treating unknown as human simply hides the uncertainty.
5. Look for convergence and fragmentation. Search for abrupt cross-device activity, mutually inconsistent preferences, shared or reassigned contact points, automated monitoring patterns, and apparently new profiles connected to established activity. Each pattern is a reason to investigate, not proof of abuse.
6. Run a counterfactual version of the decision. Recalculate the segment, score, attribution result, or forecast after excluding events with uncertain actor provenance. Then consolidate likely fragments where you have defensible evidence. If the decision changes materially, it depends on identity assumptions that need to be exposed.
7. Record the operational consequence. Note whether the uncertainty can waste media, increase message frequency, distort attribution, issue duplicate benefits, suppress a legitimate customer, or create unnecessary checkout friction. This converts identity quality from a data-cleaning concern into a prioritized business risk.

Email engagement deserves early attention because prefetching and automated summarization can create activity that resembles high engagement. An open can remain useful as a delivery or processing event, but it should not carry the same intent weight as an explicit response or a coherent downstream journey.

Do not delete ambiguous events. Preserve the raw observation and change its interpretation. Deletion destroys evidence you may need for attribution, troubleshooting, or future validation. Classification lets you ask better questions without pretending uncertain data never existed.

Replace the golden record with an evidence-backed confidence record

The traditional golden record promises one definitive profile assembled from every available identifier. That model becomes brittle when one person can produce several identities and several actors can produce events under one identity. A larger merged profile can look more complete while becoming less coherent.

Use a confidence record instead. It should not merely declare that two records match. It should explain why your organization currently considers a profile stable enough for a particular use.

Evaluate identity confidence across these dimensions:

• Identifier continuity: Are the account and contact identifiers stable over time, or do they show signs of reassignment, sharing, or frequent substitution?
• Behavioral coherence: Can the activity plausibly belong to the same customer context, or does it contain conflicting needs, abrupt channel changes, and overlapping journeys?
• Actor provenance: Can you distinguish explicit customer actions from platform processing, delegated agent activity, autofill, and unknown automation?
• Commercial continuity: Do account history, offer use, and completed outcomes support the same customer relationship, or do they reveal fragmentation or convergence?
• Ambiguity burden: How much of the profile’s apparent value depends on events whose actor or meaning cannot be established?

A practical profile record can store an identity state, actor state, confidence band, supporting evidence, contradictory evidence, last validation trigger, and permitted uses. For example, the identity state might be stable, fragmented, composite, or unknown. The actor state might be human, delegated, platform-generated, shared, mixed, or unknown.

Use confidence bands with reason codes before reaching for a precise score. A numerical score can create false certainty if nobody can explain what moved it. A band such as high, conditional, or low is useful when it is attached to evidence and an allowed decision:

• High confidence: The available evidence is coherent and sufficiently attributable for the named use. This does not mean every event came directly from a human.
• Conditional confidence: The profile contains stable evidence, but shared, delegated, or fragmented activity limits some uses. It may be suitable for service communication while remaining unsuitable as clean training data for an intent model.
• Low confidence: The profile depends heavily on weak identifiers, unknown event provenance, or contradictory activity. Use it cautiously and avoid expensive personalization or irreversible risk decisions based on it alone.

Confidence must be use-specific. The evidence required to send a general newsletter is not the same as the evidence required to grant a one-time benefit, block an order, label a person as a high-value customer, or train a predictive model. A universal identity score hides those differences.

Revalidate when meaningful evidence changes, not only during a periodic cleanup. Useful triggers include a new account relationship, a sudden shift in device or channel behavior, evidence of a shared or recycled contact point, new agent-assisted activity, conflicting transactions, and a promotion or risk event. Continuous validation is necessary because identity now behaves like an evolving relationship rather than a static match.

Identity confidence is not a reason to collect every possible identifier. Use permitted data with a clear purpose, retain provenance, and avoid treating invasive surveillance as a substitute for coherent evidence. Better validation should make your interpretation more disciplined, not make your collection indiscriminate.

Change campaign, attribution, and risk decisions at the same time

An identity audit has little value if every downstream system continues treating all events as equal. Carry the confidence state into activation, reporting, modeling, and revenue protection.

Separate activity, human intent, and identity confidence

Replace a single engagement score with distinct measures. Observed activity records what happened. Intent classification describes what the event can reasonably imply. Identity confidence describes how safely the behavior can be attached to the profile.

• Treat prefetches and automated message processing as delivery or machine-processing evidence, not direct proof of interest.
• Classify agent-based comparison and price monitoring as delegated activity. It may represent customer interest, but it should remain distinguishable from a human browsing session.
• Give coherent downstream actions more decision weight than isolated high-volume signals, while retaining uncertainty about who performed them.
• Prevent low-confidence profiles from automatically entering expensive personalization, aggressive retargeting, or high-priority sales queues.

This structure lets a campaign acknowledge useful agent activity without pretending that every machine event is a human signal.

Publish attribution with an uncertainty view

Do not hide identity ambiguity inside a probabilistic attribution model. Browser privacy changes and cross-device behavior already make attribution more dependent on inferred relationships. Adding composite profiles can make a precise report less trustworthy, even when the arithmetic is correct.

Show the reported result beside an identity-quality view. Track the share of events with unknown actors, conversions attached to composite or fragmented profiles, and the sensitivity of channel credit when automated events are removed. You do not need to invent a confidence-adjusted revenue figure if your evidence cannot support one. Showing the uncertainty is more useful than concealing it behind a new calculation.

Keep unstable identities from becoming model ground truth

A model trained to equate automated opens with customer interest will seek more people who produce the same distorted pattern. Campaigns then generate additional machine activity, which returns as apparent proof that the model was right. This is how an identity problem becomes a performance feedback loop.

Attach identity and actor labels before training. Depending on the model and decision, filter unstable profiles, reduce their training weight, or retain them as a separately labeled population. Evaluate performance by confidence band as well as in aggregate. If a model performs well only where identity is ambiguous, inspect what it has actually learned before expanding its use.

Distinguish delegated assistance from promotional abuse

An AI assistant acting for a customer is not, by itself, evidence of fraud. Shared accounts are not automatically abusive either. Blocking every ambiguous profile adds friction for legitimate customers, while permissive rules can allow one person to appear repeatedly as a new customer.

Escalate controls when low identity confidence coincides with an economic action and contradictory account history. Do not make an agent marker the sole reason for a block. Use proportionate checks, preserve the reason for the decision, and provide a review path when a legitimate customer may have been caught by the control.

Give each team an explicit responsibility

Identity confidence fails when it belongs only to the data team. Assign ownership at the point where interpretation becomes action:

• Marketing operations preserves event provenance and exposes confidence fields to campaign tools.
• Analytics reports identity uncertainty and tests how sensitive conclusions are to ambiguous events.
• Lifecycle and sales teams define which confidence bands may enter each journey or priority queue.
• Model owners document which identity states are accepted as labels and evaluate performance across those states.
• Risk and commerce teams define when an ambiguous identity warrants additional validation rather than automatic denial.

Begin with the decision that has the clearest cost when identity is wrong. Rewrite its event rules, add actor and confidence fields, rerun the decision under alternative inclusion rules, and document what changes. Once that loop works, extend the same method to the next campaign, model, or control. You will improve trust faster by validating consequential decisions one at a time than by declaring the entire customer database clean.

Key takeaways

• A marketing data doppelganger is a coherent-looking profile whose events do not reliably represent one actor or one customer’s intent.
• The problem includes both convergence, where several actors appear as one profile, and fragmentation, where one customer appears as several profiles.
• Preserve the distinction between identity, actor, and intent. A valid event does not make every person-level inference valid.
• Audit one costly decision first, recover event provenance, classify uncertain actors, and rerun the decision without ambiguous signals.
• Replace binary identity matches with explainable, use-specific confidence bands supported by evidence and contradiction records.
• Carry identity confidence into segmentation, attribution, model training, promotion controls, and reporting so the same uncertainty is not lost downstream.

Your next step is to choose one segment, score, or promotion rule that would hurt if the customer identity were wrong. Find the weakest event it relies on and make that uncertainty visible. That small change gives you a defensible starting point for rebuilding trust in the rest of your marketing data.

References

• Search Engine Land — Unveiling the Data Doppelganger Issue in Modern Marketing