Skip to content
Go to raptorservices.com
  • There are no suggestions because the search field is empty.

Testing of Tracking Implementation

Purpose of Testing

The goal of testing is to ensure that a site sends correct, complete, and consistent tracking data to Raptor before going live. Relevant for Recommendations, E-mail Triggers & Site Search.

Tracking implementation quality directly influences:

  • Recommendation relevance
  • Personalization accuracy
  • Audience segmentation precision
  • Email event generation
  • Reporting correctness

Testing must confirm:

✔ All required events fire

Visit, Basket, Buy, Favorite, ContentVisit, ItemClick, and Search, SearchClick and SearchResult if you use Site Search.

✔ Events contain the correct parameters

For example ProductId, BasketContent, Quantity, OrderId and ContentId. See Tracking Events & Parameters Reference for the full list per event. 

✔ Soft IDs and Hard IDs behave correctly

  • CookieId
  • SessionId
  • UserId
  • RuId
  • ReaID

✔ Data is stable and consistent

  • No duplicated Buy events
  • No changing CookieId
  • No missing productIds or malformed JSON
  • No unexpected ID combinations

✔ Tracking reflects actual user behavior

Events must be triggered exactly at the correct moment and never automatically or unintentionally.

Preparation

Before testing, set up these foundations.

Use a clean browser session

  • Use Chrome whenever possible.
  • Clear cookies prior to testing.
  • Avoid Safari unless testing for ITP-specific behavior.

Enable cookies and storage

Tracking requires:

  • First-party cookies enabled
  • Local storage enabled
  • No private/incognito mode (unless testing behavior under restricted conditions)

 💡 Accept the cookie consent banner on the site before testing. Tracking will not fire until consent is given. 

Know how to find the CookieId

There are two simple and reliable ways to identify your CookieId during testing. Choose whichever works best for your workflow.
 

Method 1: Visit a Rarely‑Viewed Product Repeatedly

This method ensures that your activity stands out clearly in the Live Stream.

Steps

  1. Identify a product page that normally has very few visits.
  2. Open the page.
  3. Refresh it several times — e.g. 5–10 times.
  4. Go to Live Stream in Raptor.
  5. Filter or visually scan for the product URL you’ve been refreshing.
  6. Once you find your events, open one of them and note the cookieId.

Why this works

  • Your repeated behavior creates a clear pattern.
  • Events cluster together, making them easy to spot.
  • Ideal for non‑technical testers.

Method 2: Inspect the Website → Application → Cookies → Search for “rsa”

This is the fastest and most direct way if you are comfortable with browser developer tools.

Steps

  1. Open the website.
  2. Right‑click → Inspect to open DevTools.
  3. Go to the Application tab.
  4. In the left sidebar, select Cookies for the current domain.
  5. Use the search field and look for “rsa”. (Client-side tracking)
  6. Find the cookie storing the Raptor tracking data (usually contains the CookieId).
  7. Copy the CookieId and paste it into the Live Stream filter if needed.

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

Why this works

  • The CookieId is stored client‑side.
  • Browsers store cookies per domain, so it’s always accessible here.
  • Ideal for developers or technical QA.

 

Have Raptor Live Stream open

You will use it throughout the process.

Path: Live Stream → Filter by CookieId

You should see events appear within a few seconds.

 

⚠️ If no events appear, test if tracking is blocked by script loaders, AdBlock, or inconsistent environment configuration.

 

 

Ensure you have permission to perform a test purchase

Buy events must not be tested on production checkout flows without explicit agreement.

Testing All Event Types

Each event type has:

  • Purpose
  • When it should fire
  • What parameters it must include
  • What to validate in Live Stream
  • Common mistakes

Let’s go through them in detail.

Visit

Purpose: Record the user’s page views and behavior.

When it is sent:  Every time a product detail page is viewed. 

Required parameters: EventType (p1), ProductId (p2), ProductName (p3), CategoryPath (p4), BrandId (p8), ItemPrice (p12) and StockStatus (p15). Add MasterId (p18) if your products have variants. See Tracking Events & Parameters Reference. 

 

What to verify:

✔ Visit is sent on every product page 
✔ cookieId and sessionId present
✔ cookieId does not change when navigating
✔ sessionId stays stable while tab is open
✔ ProductId matches the product feed 
✔ No duplicate Visit events per page load

Common mistakes:

  • ProductId doesn't match the product feed 
  • Event firing twice (SPA with double mount)
  • Event firing before URL is updated in SPA routers

Basket

Purpose: Track add/remove actions and cart state.

When it is sent:

  • Add to cart

  • Remove from cart

  • Quantity changes

Required parameters: BasketContent (p10): the entire basket as comma-separated ProductIds, in chronological order. BasketId (p11). ProductId (p2) only when a product is added. See Tracking Events & Parameters Reference. 

 

Validation in Live Stream:

✔ p10 contains the entire basket, not only the changed product
✔ ProductIds match the product feed 
✔ p2 is only included when a product is added 
✔ Sent only when user triggers an action
✔ Only one event per action

Common mistakes:

  • Wrong productId (UI ID instead of backend ID)
  • Price formatted incorrectly (comma instead of dot)
  • Event firing multiple times due to button re-renders
  • Sending only the changed product in p10 

 

Buy

Purpose: Register a successful purchase.

When it is sent:  Once per product in the order, immediately after the order is confirmed. 

Required parameters: EventType (p1), ProductId (p2), ProductName (p3), Subtotal (p5), Currency (p6) and ItemPrice (p12). We recommend also sending Quantity (p13), MasterId (p18) and OrderId (p21). Include UserId and RuId when the visitor is logged in. See Tracking Events & Parameters Reference. 

 

Validation in Live Stream:

✔ One Buy event per product in the order 
✔ No product is sent twice 
✔ Quantities correct
✔ Prices correct
✔ orderId unique
✔ UserId / RuId present if user logged in

 

⚠️ Critical warnings:

  • Never fire Buy on page load.

  • Ensure Buy client-side and server-side do not duplicate.

  • Use full decimal format for prices.

Favorite

Purpose: Track wishlist additions/removals.

When it is sent: User favorites or unfavorites a product.

Required parameters: FavoriteListContent (p14): the entire favorites list as comma-separated ProductIds, newest first. FavoriteListId (p23). ProductId (p2) only when a product is added. 

Validate:

✔ Correct productId
✔ p14 contains the entire favorites list 
✔ Event sent only on user action

 

ContentVisit

Purpose:  Track pages without products, such as articles, guides and blog posts. 

Required parameters: ContentId (p9). We recommend also sending ContentName (p26), ContentTag (p27) and ContentCategory (p28). 


Validate:

✔ Correct contentId
✔ ContentCategory uses the same format as CategoryPath 
✔ No duplicates

 

Search (only required when implementing Site Search)

Purpose: Capture search queries.

 

Required parameters: SearchPhrase (p17) 

Validate:

✔ Query is exactly what user typed
✔ Sent only when submitting, not on typing

 

SearchResult (only required when implementing Site Search)

Purpose: Record search result impressions.

Required parameters: SearchResult (p31): the product IDs shown, as a comma-separated list 


Validate:

✔ ProductIds correct
✔ Positions sequential (1, 2, 3…)
✔ Matches SearchClick positions

 

SearchClick (only required when implementing Site Search)

Purpose: Record clicks on search results.

Required parameters: ProductId (p2). Optional: SearchResultPosition (p30) 

Validate:

✔ position matches SearchResult
✔ sent at click event only

 

ItemClick

Purpose: Track product clicks in recommendation modules and carousels.

Required parameters: ProductId (p2) and the name of the clicked module (moduleName) 

Validate:


✔ Correct productId
✔ moduleName matches the module that was clicked 
✔ No duplicate events

 

Testing User Tracking (Soft ID + Hard ID)

User tracking controls personalization.
This must be tested deeply.

Soft ID: CookieId

Expected behavior:

✔ Created on first page load
✔ Persistent
✔ Stays the same for all events
✔ Only changes if user clears cookies or expires

Test:

  • Reload pages
  • Navigate site
  • Open new tab

CookieId should stay the same.

 

SessionId

Expected behavior:

✔ Changes when session ends
✔ Should NOT change inside a single browsing session

Test:

  • Open page
  • Click around → stable
  • Close browser → reopen → new sessionId

 

Hard IDs: UserId, RuId, ReaID

4.3.1 UserId

Set when user logs in.

Validate:

✔ Appears instantly after login
✔ Stays consistent across events
✔ Disappears on logout

 

RuId

Can be:

  • Email (most common)
  • External ESP ID
  • CRM ID

Validate:

✔ Correct value
✔ Not exposed before login unless intended
✔ Included in Buy event if user logged in

 

ReaID

Used for email tracking.

Validate:

✔ ReaID appears on visit after coming from email link
✔ Does not appear otherwise
✔ Correctly associated with CookieId and UserId

 

Test the User Identification Journey

Perform this full flow:

  1. Visit site logged out → soft IDs only
  2. Log in → UserId + RuId appear
  3. Add to basket → hard IDs included
  4. Buy → hard IDs included
  5. Logout → revert to soft IDs

Test All Three User Identification Scenarios

Test the scenario that matches your ID strategy. The three scenarios are described in User Tracking: Understanding Soft IDs, Hard IDs & Raptor Identity Matching. 

Scenario 1: UserId + RuId = email

Most implementations.

Validate:

✔ Email only appears after login
✔ Stays stable through session
✔ Buy event includes it

 

Scenario 2: UserId + External ESP ID

Validate:

✔ ESP ID consistent
✔ No mixing with email

 

 Scenario 3: One global ID for web and e-mail 

Validate:

✔ The same ID is sent as both UserId and RuId 
✔ ReaID sync is only enabled if the global ID is an e-mail address 

 

Special Notes & Edge Cases

Pageview = Visit

Partners sometimes expect both. Clarify only Visit is used.


SPA frameworks

Common issues:

  • Event is sent before route updates
  • Double-mounting fires duplicates
  • Cached components re-fire events


Safari ITP

Cookie lifetime reduced dramatically.
Validate with:

  • Chrome → baseline behavior
  • Safari → understand constraints


Server-side safety

Buy events MUST NOT fire:

  • On page load
  • On refresh
  • On order confirmation page reload


Final Testing Checklist (Extended)

Events

  • Visit
  • Basket (add/remove)
  • Buy (one per product) 
  • Favorite
  • ContentVisit
  • Search
  • SearchResult
  • SearchClick
  • ItemClick

Data correctness

  • ProductIds match catalog
  • Prices, quantities correct
  • No duplicate events

User tracking

  • CookieId stable
  • SessionId correct
  • UserId on login
  • RuId present
  • ReaID sync works

Scenarios

  • UserId + email
  • UserId + external ID
  • Global ID

Technical health

  • No console errors
  • No tracking blocked
  • SPA routing handled
  • Server-side events not duplicated

 

Final Note

Once the implementation is approved, you can keep an eye on tracking quality in the Live Tracking Stream, follow long‑term data health in Tracking Stats, and monitor recommendation performance in the Account Dashboard. We also recommend setting up Operational Insights notifications to be alerted early if anything changes. These tools make it easy to spot issues quickly and ensure the setup keeps performing as expected.