Testing of tracking implementation - relevant for Recommendations, E-mail Triggers & Search

When tracking has been implemented on a website, you’ll want to test and validate that everything is working as intended by following these steps:

Step 1

Preparation

• To complete a test of the 'buy event', request a way to make a “test purchase”.
• Sign up to all the relevant newsletters. (Remember to double opt in if needed)
• Identify your cookie ID.

Go to the website that you have implemented tracking for. Accept cookies. Visit products/areas of the website that you can recognize, then search for your behavior in the Raptor Control Panel: 

- Go to Data Management

- Selecting “Live Tracking Stream”

OR you can find the Cookie ID while on the website, by going to “Application”

Client-side: If the Raptor script is used, the name of the cookie will be "rsa" or "rsa[accountId]"

Server-side: If the tracking is implemented Server-side, it is the customer who defines the name of the cookie.

Step 2

Testing the tracking of all implemented event-types

This step-by-step guide will help you compare your test-results with the event-tracking documentation.

Visit

Every time a Product Detail Page (PDP) is viewed, a Visit Event should be fired. Visit-type events can be useful in many aspects of Raptor solutions, as these events are fundamental in the Recommendation Algorithms. They can also be used in the CDP, via the Audience Builder, to find people who visited specific products/content.

1. Visit a product.
2. Make sure all parameters are sent to the correct locations and in the correct format. It is recommended that you visit multiple products during this test.
3. ProductId sent in P2 must be in the the correct format and match the ProductId in the Product Catalog. For more details, read our documentation on Product Data.
4. Remember to follow the steps in Step 3: User Tracking.

Basket

Every time a user adds a product to their basket, removes a product from their basket or clears out their basket, a Basket Event should be fired. This event is mainly used for the abandoned basket trigger, but also for feeding the Recommendation Engine with information about what the users add to their basket – an important datapoint for personal recommendations. 

Basket-type events can be useful in many aspects of Raptor solutions, as these events are fundamental in the Recommendation Algorithms. They can also be used in the CDP, via the Audience Builder, to find people who have added something to their basket.

1. Add a product to the basket.
2. Add one more product to check that BasketContent (P10) is updated with two IDs.
   • If the same ID was added twice, the ID should only be sent to BasketContent once.
3. The added ID must be in P2.
4. If BasketId is tracked, this ID must also be set (P11).
5. The ID that is set in BasketContent must match the ID in P2 on 'visit' events.
   ATTENTION! Fashion brands often put ID with Size in BasketContent. This is generally a bad idea.
6. Now, remove one product from the basket and check that a new Basket Event is fired, with the updated BasketContent.
   • P2 must not be fired when adjusting the basket.
7. Remove all products from the basket. A Basket-type event must be fired where BasketContent is empty. (Not "Null", but empty.)
8. If BasketId is tracked, this must be sent with the above events so that Raptor’s systems know that the relevant BasketId no longer contains any of the products.
9. The BasketId must not be changed at any point during the customer’s journey.
10. If there is a powerstep that allows you to add products directly to the basket, then the basket tracking must also work from there.
    • In addition, an 'itemclick' must be fired at 'add to basket' if this is a Raptor Recommendation module.
11. Remember to follow the steps in Step 3: User Tracking.

Favorite (wishlist

Every time a user adds something to their favorites, removes something from their favorites or clears out their favorites-list, a Favorite Event should be fired. This event is used for feeding the Recommendation Engine with information about what the users add to their favorites list, but is also utilized by Behavioral Triggers such as Abandoned Favorites, Price Drop Favorites, Back In Stock Favorites and Campaign Favorites. (Some sites refer to this favorites list as a "wishlist". In the Raptor Control Panel, we use ‘favorites list’ as a general term for wishlists and similar systems.)

Favorite-type events can be useful in the following aspects of Raptor Solutions: Web Recommendations, E-mail Recommendations, E-mail triggers, and the CDP. These events are used in the Recommendation Algorithm and can be used in the CDP, via the Audience Builder, to find people who have added something to their favorites list.

 

1. Add a product to the favorites list.
2. Add one additional product to check that the FavoriteListContent is updated with two IDs.
   • If the same ID is added twice, you should only see the ID in FavoriteListContent once.
3. The added ID must be set in P2.
4. If FavoriteListId is tracked, this ID must also be set.
5. The ID that is set in FavoriteListContent must match the ID in P2 for Visit-type events.
   ATTENTION! Fashion brands often put ID with Size in FavoriteListContent. This is generally a bad idea.
6. Now, remove one product from the favorite list to check that a new Favorite Event is fired with the updated favorites list.
7. P2 must not be fired when removing a product from the list.
8. Remove all products from the favorites list. A Favorite Event must be fired where FavoriteListContent is empty. (Not "Null" but empty.)
9. If FavoriteListId is tracked, this must be sent in the above-mentioned events so that Raptor’s systems know that the relevant FavoriteListId no longer contains any of the products.
10. The FavoriteListId must not be changed at any point during the customer’s journey.
11. If there is a powerstep that allows you to add products directly to the favorites list, then the favorite tracking must also work here.
    • In addition, an ItemClick must be fired at 'add to favorites' if the product that was set to the list was from a Raptor Recommendation module.
12. Remember to follow the steps in Step 3: User Tracking.

Buy

The Buy Event should be fired when someone views the final confirmation-page, or otherwise completes the ordering-process. Specifically, the Buy Event should fire for every individual product within the order. For example, if a customer buys 1 unit of product A and 2 units of product B in a single order, two buy events should be sent. The Buy Event is vital for analyzing the overall performance of the business, combining products, and making personal recommendations.

Buy-type events can be useful in many aspects of Raptor solutions, as these events are fundamental in the Recommendation Algorithms. They can also be used in the CDP, via the Audience Builder, to find people who have purchased something.

1. In Step 1, acquiring credentials for completing test-purchases was mentioned. This will now come in handy.
2. Buy multiple products to check that unique ProductId's are handled correctly.
   • Buy two of the same ProductId to check that it is sent in one line
     • The subtotal should hold the sum of the two products (ItemPrice x2).
   • Buy two different ProductId and check that two lines are fired.
3. Check that all parameters are sent in the correct format.
4. ProductId in Buy-type events must be the same as in Visit, Basket, etc.
5. It is recommended that you test different means of payment, if possible.
6.  Remember to follow the steps in Step 3: User Tracking.

 

Search

Every time a customer uses the search-bar, a Search Event should be fired. This helps the Recommendation Engine connect search results with products and content, and vice versa.

Search-type events can be useful in many aspects of Raptor solutions, since these events are used by the Recommendation Algorithms. They can also be used in the CDP, via the Audience Builder, to find people who have searched for something.

1. Search for something on the website to check that the SearchPhrase is set in P17.
2. Remember to follow the steps in Step 3: User Tracking.

ContentVisit

When a user visits a Content Page the ContentVisit Event should be fired. A Content Page is a type of page that features text, images, videos, etc. - but does not include products. This enables all Recommendations based on content. 

ContentVisit Events can be useful in the following aspects of Raptor Solutions: Web Recommendations, E-mail Recommendation, and CDP. These events are used in the Recommendation Algorithms, and can also be used in the CDP, via the Audience Builder, to find people who have visited/read content.

1. Visit various Content Pages on the website.
2. Make sure that the ContentId (P9) matches the ID in the Content Feed.
3. Remember to follow the steps in Step 3: User Tracking.

 ItemClick (only required when implementing Website Recommendation)

The ItemClick Event should be fired every time a user clicks on a Raptor Recommendation. If the user can add products to the basket directly from the Raptor Recommendation spot, the Basket Event should also be fired from there. The ItemClick Event is used for tracking the performance of the Website Recommendation Modules.

1. Check that the 'ItemClick' fires when clicking a product from a Raptor Recommendation module
   • Ensure that the ProductId at 'visit', 'buy', 'basket' matches the ID for ItemClick.
2. Check that the module name is set with the correct API name. Eg. "GetSimilarItems". (This is needed for Analytics & Insights to show reporting.)
3. If there is a powerstep from where you can add products to the basket directly, then an ItemClick Event must be fired when a product is added to the basket.
4. Remember to follow the steps in Step 3: User Tracking.

Step 3

User Tracking

By default, Raptor utilizes cookies to identify all website visitors. However, in order to match visitors with a contacts database we have to explicitly identify known visitors, such as logged-in users or anonymous visitors who provide their email address or other IDs online. This forms the foundation for cross-device user identification. Please refer to our documentation for further details.

Soft ID

1. CookieId must be sent as a GUID. (uuid v4)
2. Make sure the CookieId is the same for all events throughout the entire customer journey.
3. Carry out all the above actions in Step 2 and see that the CookieId does not change.
   • Pay particular attention to 'buy' events.

Hard ID

Make sure you have REAID sync in place, and that REAID is added to newsletters, before this is tested.

Hard IDs can be set in the following ways:

• Create a user
• Login
• Signup for newsletter
• Purchase
• Click in a newsletter.

 

Scenario 1:

You have two different hard IDs being used to identify users across your website and e-mail marketing provider - User ID and E-Mail.

Hard ID for Website Recommendations and Site search: The unique ID for logged-in users should be sent in the parameter UserId (WebsiteID).

Hard ID for E-mail Recommendations and E-mail Triggers: If the ID used by the e-mail marketing provider is an e-mail, simply send the email as RUID and activate REAID Sync.

1. Create a user
   • Check that an ID is set in WebsiteId (P7) and that the user's e-mail is set in RUID (base64 encoded)
2. Login
   • Check that an ID is set in WebsiteId (P7) and that the e-mail used is set in RUID (base64 encoded)
3. Sign up for the newsletter
   • When signing up for the newsletter, the WebsiteId will not be available. Therefore, you need only check that e-mail is set in RUID (base64 encoded)
4. Purchase without log-in
   • Check that e-mail is set in RUID. The website ID will typically not be known at this time, so P7 should not be set.
5. Purchase with log-in
   • Here the WebsiteId is already known, so this must be set in WebsiteId (P7) and e-mail must be set in RUID.
6. Click in the newsletter
   • If the RUID is an email, REAID must be enabled. When clicking on the newsletter, the REAID must be shown in REAID.

 

Scenario 2:

You have two different hard IDs being used to identify users across your website and e-mail marketing provider - User ID and External Marketing ID.

Hard ID for Website Recommendations and Site search: The unique ID for logged-in users should be sent in the parameter UserID. (Website ID).

Hard ID for Email Recommendations and Email Triggers: If the ID used by the e-mail marketing provider is an External marketing ID (anything other than an email), simply set your Hard ID as RUID, and do not activate ReaId sync.

1. Create a user
   • Check that an ID is set in WebsiteId in P7, here the user’s External Marketing ID is typically not known, which is why it cannot be set.
2. Login
   • Check that an ID is set in WebsiteId in P7, here the user's External Marketing ID is typically not known, which is why it cannot be set.
3. Sign up for newsletter
   • When signing up for the newsletter, neither the WebsiteId nor the External Marketing ID will be available, which is why no IDs can be set.
4. Purchase with log-in
   • Put the WebsiteId in P7, the External Marketing ID will not be recognized at 'login', so it cannot be put in the RUID.
5. Purchase without log-in
   • No IDs can be set here.
6. Click In the newsletter
   • Here, the customer's External Marketing ID must be set as RUID in the URL.

 

Scenario 3:

There is a global ID used across both web and email, ensuring that the user has the same Hard ID in all instances.

In this scenario, send the ID as both UserId (Website ID) and RUID (Raptor Email Marketing ID).

This scenario is somewhat rare, but when it does occur, it is important that the ID is set in both WebsiteId (P7) and RUID, even if it is the same ID that is set twice.

User recognition

In relation to user recognition, it is important to understand the consequences of the choices made in the process above.

We differentiate between identified profiles and anonymous profiles. A profile consisting only of a cookie ID is considered anonymous. An anonymous profile is indeed useful for Product Recommendations and targeting of Merchandising campaigns, and it will be part of your audiences. You will, however, not be able to target anonymous profiles in your email marketing campaigns or in campaigns on social media. 

From the Raptor Control Panel, go to Analytics & Insights to find E-mail Personalization, and "Mapped Email Recipients". This graph shows the development of the total number of recipients that Raptor has mapped and identified – these are the customers that can be targeted by email-based Personalized Recommendations.