The following are the steps to identify website visitors:
If a visitor lands on your website from an external source, the source must send a unique ID for that visitor to your website. This can be sent in the redirect URL, cookie value, or any other web pass mechanism. You must store this unique ID on the website and persist it across the session cookie. Acquia recommends that you persist the unique ID information for a browser session.
After you receive the information from the external source, you must forward the same to CDP through the CDP WebTag library or DW Tracker API. CDP identifies the website visitors by leveraging this data. You must pass the unique identifier in the payload of the HTTP call based on the authentication status of your website visitor.
User is logged in to your website:
customer:
{
SourceCustomerNumber: <Unique ID linked to the email value. The format
of this parameter varies for each tenant. For example,
360profile_customer_13.>
UUID: <Unique ID. For example, 12345.>
Email: <Email used by the visitor to log in to the website. For
example, [email protected].>
*Other data points in this object remains same as desired*
}
event:
{
SourceCustomerNumber: <Unique ID linked to the email value. The format
of this parameter varies for each tenant. For example,
360profile_customer_13.>
Email: <Email used by the visitor to log in to the website. For
example, [email protected].>
*Other data points in this object remains same as desired*
}
User is not logged in to your website:
customer:
{
SourceCustomerNumber: <Unique ID. The format
of this parameter varies for each tenant. For example,
360profile_customer_13.>
UUID: <Unique ID. For example, 12345.>
*Other data points in this object remains same as desired*
}
event:
{
SourceCustomerNumber: <Unique ID. The format
of this parameter varies for each tenant. For example,
360profile_customer_13.>
*Other data points in this object remains same as desired*
}
Important
If CDP is able to identify the website visitor during the same session, all anonymous events are associated with the known user. CDP defines a session as a 30 minute window before or after identification.
If you have already integrated CDP WebTag with your system, you must try to
send SourceCustomerNumber
or Email
, even if the user is not
currently authenticated on the website. You can achieve this by using an
identification cookie. Such cookies are set to any known user and can be
used on subsequent visits to the website. The cookies behave similar to
cart cookies that save the items that are currently in your cart even if
you leave the page and return after some time.
The SourceCustomerNumber
or Email
values must not be cached to
ensure that CDP accurately identifies the users generating the events.
The external source integrated with your system must send a customer feed with all the desired customer attributes. This helps CDP to build the customer profile. CDP can link the behavior from the website to the customer profiles built through the customer feed.
Let us assume that CDP receives the following values:
SourceCustomerNumber |
UUID |
Source System |
Name |
|
---|---|---|---|---|
12345 |
- |
12345 |
Webtag |
- |
A34567 |
12345 |
Webtag |
- |
|
12345 |
12345 |
External Source |
- |
|
A34567 |
- |
Customer Data Source |
ABC |
CDP maps the preceding values from Customer Feed - External Source to both SourceCustomerNumber and UUID.
This results in the following customer summary record:
Master Customer |
UUID |
Name |
|
---|---|---|---|
12345|A34567 |
12345 |
ABC |
After you pass your visitor’s identification, you can enable CDP to tie the identification to the existing contacts. You can review the events that CDP tracks. For more information, see List of tracked events.