Overview
Customers can track website visitors in Cheetah. The visitors can be anonymous or known and can be tracked at any level of detail. Websites can also use Cheetah to show personalized content to visitors, which is an effective way of increasing membership in the loyalty program.
Also see Cheetah Web Tracking, which deals with recording web behaviors in order to drive personalized content via segmentation. Web Tracking applies to both visitors and members.
Visitors are Member
Just not “verified” members.
Cheetah tracks each website visitor as a provisional loyalty program member called a Cheetah Visitor. Cheetah Visitors are not full/verified Members since they have not formally accepted the loyalty program “terms of use”. In fact the visitor probably does not know he/she has a provisional membership.
Visitors do not have tiers or points. Even if content such as Challenges are targeted at Visitors, they will be prompted to sign up for the loyalty program before they can earn or redeem points.
However, they do exist as Member records in Cheetah, where the admin can view their information, create reports, and target them with content. Cheetah automatically makes other distinctions for Visitors. For example, Visitors do not receive a “welcome” email and are excluded from mailings such as monthly statements.
Tip: Each Member has a “Visitor” attribute in their profile; visitor=true indicates a Visitor and visitor=false indicates a full Member.
Anonymous, known, or well-known?
Visitors can be anonymous or known, but this is more of a continuation than a hard line. The traditional definition of a known visitor is that you have their email . Cheetah goes beyond known visitors, allowing the website to collect information through Moments and Challenges, so that the visitor becomes well-known. For example, a website can passively infer and record member preferences based on where they go on the website, or actively show pop-up questions to collect an email address or directly ask for a preference or opinion.
Tip: Cheetah Web Tracking can be used to record visitor behaviors.
Content Targeting
Visitors are Members, so Cheetah can show targeted content such as Offers. All of the information collected for the Visitor can be used for Cheetah content targeting and segmentation. For example, a customer could collect the visitor’s region and use that to target content.
Visitor Tokens
A website can track a visitor by creating a Cheetah Visitor Token, a hash of the most important information known about the visitor. This might be almost nothing for anonymous visitors, or it might include detailed information for well-known customers. When available, the typical pieces of information to include are email, first name, last name, and a user id. However, a Visitor Token can still be created even if none of this is known.
Multiple Visitor Records
Websites that automatically create Visitors (by using Visitor Tokens) can associate more than one Visitor (member record) with a real-world person. This can happen if the person has visited the website on more than one device, uses more than one browser (Safari and Chrome) or clears his browser cookies. The various Visitors will each have independent tracking information recorded for them. This is an important nuance to understand, as it affects Visitor Conversion and Visitor Merge scenarios (see below).
Visitor Conversion
Programs want Visitors to signup for the loyalty program. This converts the Visitor to a full verified Member. Whenever possible, Cheetah will attempt to update an existing Visitor member record rather than create a new member, which preserves the Visitor history.
Note: A Visitor (visitor=true) who signs up for the loyalty program becomes a full Member (visitor=false).
Conversion Methods
Correctly determining when and which Visitor member record to update is critically important, and Cheetah uses a few different strategies for this depending on which information is at hand.
Note: Visitors can sign up by filling out the sign up form (the Cheetah Login Element in our JS SDK) or through website integration (SSO).
Integration ID
The customer website can maintain a unique user ID and either call the Cheetah SSO API or include the user ID in the Visitor Token. Cheetah calls this the “Integration ID”. This works well if the customer website has a login or means to identify users.
Email Address
Sometimes the email address of a Visitor is already known, for example if a Visitor subscribed to a mailing list. If a user signs up using the same email address as an existing Visitor will update that member record instead of creating a new record. Clicking a link from an email can also be used to identify a Visitor.
Phone Number
Similar to an email address, if a user signs up using the same phone number as an existing Visitor will update that member record instead of creating a new record.
(Visitor) Member ID
A customer website might have created an Anonymous Visitor in order to track interesting behaviors (also see Cheetah Web Tracking). In this case the member record will not have a phone number or email address, so the looked is based on Member ID. Unlike email address or phone number, this approach will only work if the user uses the same browser sign up.
Note that Cheetah only uses this approach for Visitors; any verified Member must login with username/password.
Security
As a matter of security, Cheetah requires all verified Members to login using username/password, or via SSO with the customer website.
The Cheetah API only allows Visitors (visitor=true) to be looked up and updated during signup, not verified Members (visitor=false). Signing up sets visitor=false, and afterwards the logins for that Member may require username/password.
Unconverted Visitors
Not every Visitor will convert to a verified Member. Not everyone who visits the website will sign up or even return, and users occasionally clear their browser cookies. Visitors who have not converted to verified Members within a reasonable span of time (6 months or so) should be purged from the system to avoid the build-up of cruft.
Visitor-to-Member Merge
This section deals with the topic of merging a Visitor record into a Member record. A person who has signed up for the loyalty program as a verified Member could still have a Visitor record, such as on a different browser or device.
Scenario 1: Visitor Conversion
This is a recap of the Visitor Conversion scenario described in the previous section. This is not a merge scenario, but is useful context.
-
A user visits the website on his laptop, creating an anonymous Visitor.
-
The user signs up as a member.
-
Results:
a. Update the Visitor to a verified Member (visitor=false).
b. Apply any post-signup behaviors, such as a redirect to member page.
Scenario 2: Using Multiple DevicesAxwn
-
A user visits the website on his tablet, creating an anonymous Visitor.
-
The user signs up on his laptop, creating a Member.
a. The order of steps 1 and 2 do not matter.
-
The user then logs into the website on his tablet.
-
Results:
a. During login the client changes the authenticated user from the Visitor to Member.
b. Unlike Scenario 1, the client must not update the Visitor to become a Member. Instead the client must identify that a merge is necessary, where the Member is the primary record and Visitor is secondary.
c. The client will then call the /visitor/merge API endpoint. Note that the Member is the currently authenticated user, so this API call is made in the context of the Member (not the Visitor). The /visitor/merge endpoint accepts the member id of a Visitor (visitor=true) for this operation.
d. The /visitor/merge endpoint will update the primary record (Member) with any interesting information that was previously recorded on the secondary record (Visitor).
This includes: - All activities - Member attributes which are null in the primary member record, and non-null in the secondary member record. - Does the Visitor have a signup activity? Could we use a different activity? That would make merge simpler. - we added sl_visitor_signup latere. Flag the secondary record (Visitor) for cleanup.
Scenario 3: Open Visitor Email
This is a very common scenario for customers who have mailing list subscriptions. This would also apply to customers who buy lists and blast emails for lead generation, however we do not expect our customers to do that with our platform.
-
A user visits the website on his laptop, creating an anonymous Visitor.
-
The user signs up for a newsletter mailing list, providing his email address.
-
The program uploads the mailing list containing the email address (and probably many others) into Cheetah. This results in a known Visitor being created with the email address.
-
The program sends an email to the known visitor email address, either through Cheetah or their ESP.
-
The user opens the email on his laptop and clicks a link to the website.
-
Results:
a. The email link contains a token that identifies the known Visitor.
b. Identify that the known Visitor is the primary record, and anonymous is secondary.
c. Update primary record (known Visitor) with any interesting information that was previously recorded on the secondary record (anonymous Visitor). We may want to introduce “Merge Rules” on attributes and activities for this.
d. Update any persistent settings stored on the browser client (e.g. cookies) to be consistent with the primary record (known Visitor).
e. Flag the secondary record (anonymous Visitor) for cleanup.
Scenario 4: Open Member Email
This is a negative scenario, with no member merge.
-
A user visits the website on his tablet, creating a Visitor.
-
The user signs up on his laptop, creating a Member.
-
The program sends an email.
-
The user opens the email on his tablet and clicks a link to the website.
-
Results:
a. There is a Visitor record for the website, but the email link identifies a member.
b. Due to security considerations, Cheetah must not automatically login the member.