Skip to main content
This guide is intended to be used alongside the core documentation for implementing the Customer Engagement to Product Discovery integration. For full reference on how discoveryKey works and how to implement it correctly, see here.
To identify why Product Discovery sessions are not matching Customer Engagement contacts, resulting in a low share of connected sessions. Typical symptoms include:
  • Very low share of connected sessions (less than 5%)
  • Returning customers not being recognised
  • Limited personalisation impact

​
Core principle

A session becomes connected when, in an Product Discovery session, a customerKey of X is matched to a Customer Engagement contact with a discoveryKey of the same value X. To summarise, these conditions must all be true:
  1. The Product Discovery session contains a customerKey
  2. The Customer Engagement contact has a discoveryKey
  3. customerKey = discoveryKey
Some of the investigations below require access to Product Discovery Health Overview or Customer Engagement contact data. Depending on the access available to the developer or implementor, these steps can be carried out together with Voyado.

​
1. Establish current state

Start by:
  • Checking the share of contacts in Customer Engagement with a discoveryKey assigned is the most important indicator and the right place to start. A well-implemented setup should have 90%+ coverage. If you are below this threshold, read more here about how to increase your share of contacts with a discoveryKey. If in-store registration is part of your model, see step 6 for guidance on how to handle this correctly.

Learn how to boost the amount of contacts with a discoveryKey

Then check:
  • Share of connected sessions in Product Discovery Health Overview
  • Share of customers with purchases without a discoveryKey
  • Whether all purchases are sent to Customer Engagement or only member purchases
Connected sessions typically range 5–40%. Where you sit in that range depends heavily on:
  • The share of contacts in Customer Engagement with a discoveryKey
  • How often visitors are identified, a loyalty-heavy retailer with mandatory login should be at the high end; a guest-checkout-heavy retailer will naturally sit lower.

Show me the contacts bulk API

​
2. Assignment of discoveryKey

Is discoveryKey being set, and is it set correctly? When a user is identified, customerKey in Product Discovery and discoveryKey in Customer Engagement must have the same value. Check:
  • Which identifier is used as customerKey
  • Whether the same value is used as discoveryKey in Customer Engagement
  • When discoveryKey is set (login, checkout, purchase, etc.)
  • Whether discoveryKey is included in all Customer Engagement API requests that support it — discoveryKey is supported on contact create, update and bulk endpoints only
Verify by inspecting the contact create/update API requests sent to Customer Engagement upon identification. Common issues:
  • discoveryKey not included in all Customer Engagement requests
  • discoveryKey set too late in the flow
  • customerKey and discoveryKey using different identifiers
  • A new customerKey generated instead of reusing the existing one
  • Existing Customer Engagement contacts missing discoveryKey entirely
Resolution:
  • Send discoveryKey consistently in all Customer Engagement calls
  • Set discoveryKey as soon as the user is identified
  • Align customerKey and discoveryKey to the same identifier
  • Reuse the existing customerKey for returning visitors
  • Update existing contacts when they are next identified

​
3. ID consistency across systems

Is the same identifier used consistently everywhere? Even if discoveryKey is being set correctly, inconsistent identifiers across systems will prevent sessions from connecting. The same identifier must flow through:
  • Product Discovery session → customerKey
  • Product Discovery events → customerKey
  • Customer Engagement contact → discoveryKey
  • Customer Engagement events (including purchase) → discoveryKey
Common issues:
  • Different identifiers used across systems
  • The existing customerKey not being reused when a visitor is identified (e.g. at login), causing a mismatch with the discoveryKey in Customer Engagement
  • A new customerKey generated instead of reusing the existing one
  • Purchase events sent to Customer Engagement before discoveryKey has been applied in the same flow
Resolution:
  • Use one stable identifier for both customerKey and discoveryKey
  • When a visitor is identified (e.g. at login), reuse the existing customerKey — or if a known customerKey is retrieved from the user account, switch to that and update the client side accordingly
  • Ensure discoveryKey is set and purchase events are sent in the correct order within the identification flow

​
4. Analyse unmatched customerKeys

Product Discovery Health Overview can provide a sample of customerKeys for returning customers (purchase within last 6 months) that don’t match any discoveryKey in Customer Engagement. This step can be done together with Voyado if access to Health Overview is limited. For each customerKey in the sample, check:
  • Does the customerKey exist in the ecom system, and which contact does it belong to?
  • Does that contact exist in Customer Engagement?
  • Does the Customer Engagement contact have a discoveryKey?
  • Does the discoveryKey match the Product Discovery customerKey?
  • Are multiple contact profiles present for the same user?
Possible explanations:
  • discoveryKey is missing
  • discoveryKey is not equal to customerKey
  • Only member purchases sent to Customer Engagement
  • Incorrect identification at checkout
  • customerKey regenerated instead of reused
If the volume is large, consider a bulk update. If your system holds both the Product Discovery customerKey and the Customer Engagement contactId, a bulk import can backfill discoveryKeys for existing contacts quickly.

Show me the contacts bulk API

​
5. Verify soft ID / email channel identification

Visitors arriving via email links should be identified automatically via the soft ID (eclub) parameter. This is one of the highest-leverage identification touchpoints and a common gap.

Read more about soft identification

The following checks require Voyado’s involvement, raise these with your Voyado team:
  • Is soft identification enabled for this environment?
  • Does the decrypted soft ID payload include the discoveryKey field? (Not on by default — requires explicit activation by the Voyado team)
Depending on the configuration, identification works as follows:
  • If soft ID is active and discoveryKey is included in the payload, the website can use it directly as the customerKey in Product Discovery
  • If discoveryKey is missing from the payload, the website can still identify the visitor via the contactId and retrieve the associated customerKey from the e-com system
  • If soft ID is not used at all, identification relies on whether a customerKey is already available client-side, for example from a cookie

​
6. Check in-store recruits

Members recruited in-store often have no discoveryKey because there is no browser session at the point of sign-up. This can be a significant source of unmatched contacts, particularly for retailers with large physical store networks. Resolution options:
  • Generate a customerKey at point of in-store registration and store it in Customer Engagement immediately
  • If that is not possible, send a verification SMS or email as a double opt-in. If email is used and soft ID is enabled, the visitor will be identified automatically on click. With SMS, add the contactId as a shortGUID in the URL and handle identification on landing.

Read about boosting discoveryKeys

​
7. Verify identification logic

A code-level review to confirm the implementation matches the expected behaviour described in steps 2 and 3. Check:
  • On login or checkout, is customerKey aligned with discoveryKey?
  • Is the updated identifier used in all subsequent events and purchases?
Common issues:
  • customerKey generated multiple times instead of reused
  • customerKey not updated after identification
  • discoveryKey not included in Customer Engagement events post-identification
  • Purchase events sent before identification has been applied

​
Expected outcome

A well-implemented setup typically delivers connected sessions in the 20–40% range for loyalty-driven retailers. Higher connected session rates directly enable:
  • More relevant product recommendations
  • Audience-based onsite personalisation
  • Behaviour-driven marketing in Customer Engagement
For retailers this typically results in improvements to conversion rate, average order value, and revenue per visitor.

Read more about the connected capabilities