Tracking — Frequently Asked Questions
How Tracking Works
Section titled “How Tracking Works”How does CustomerLabs collect event data?
Section titled “How does CustomerLabs collect event data?”CustomerLabs collects data in two ways:
- Client-side — A JavaScript tracking code installed in your website
<head>fires events directly from the user’s browser. It automatically captures page views, assigns an anonymous user ID, and collects browser signals like click IDs and cookies. - Server-side — Backend integrations (Shopify webhooks, CRM sources, API calls) send events directly to CustomerLabs from your server. These are not affected by ad blockers but lack browser-level signals unless unified with client-side events.
Most implementations use both together — client-side for browser signal capture, server-side for reliable conversion data.
What is the CLUID (CustomerLabs User ID)?
Section titled “What is the CLUID (CustomerLabs User ID)?”The customerlabs_user_id (CLUID) is a unique anonymous identifier assigned to every visitor automatically on their first page load. It persists across pages and sessions and serves as the foundation for identity resolution — it is later enriched with PII (email, phone) when the user identifies themselves via a form submission or login.
What events are tracked automatically?
Section titled “What events are tracked automatically?”CustomerLabs automatically fires a Page View event on every page load. All other events — such as button clicks, form submissions, add-to-cart, and purchases — must be explicitly implemented using the CustomerLabs JavaScript API or a backend integration.
What is the difference between client-side and server-side events?
Section titled “What is the difference between client-side and server-side events?”| Client-Side | Server-Side | |
|---|---|---|
| Source | User’s browser | Your server or backend |
| Ad blocker affected | Yes | No |
| Captures browser signals | Yes (fbp, fbc, click IDs) | No |
| Reliability | Lower (browser dependent) | Higher |
| Best for | Page views, clicks, form starts | Purchases, form completions, CRM events |
Installation
Section titled “Installation”Where should I place the CustomerLabs tracking code?
Section titled “Where should I place the CustomerLabs tracking code?”Paste the tracking code inside the <head> tag of every page, before the closing </head>. Placing it in the <body> or at the bottom of the page causes the CLUID assignment and page view to fire late or be missed entirely.
My tracking code is installed but no events are appearing — what should I check?
Section titled “My tracking code is installed but no events are appearing — what should I check?”- Confirm the Account ID in the tracking code matches your CustomerLabs account — the generic snippet contains a placeholder that must be replaced.
- Verify the domain is added to the Authorized Domains list in CustomerLabs Events Manager.
- Open the CustomerLabs Pixel Helper Chrome extension and reload the page — it will show whether the code is firing and flag any errors.
- Check Monitoring → Source Logs and filter by your domain to confirm events are reaching CustomerLabs.
Can I install CustomerLabs through Google Tag Manager?
Section titled “Can I install CustomerLabs through Google Tag Manager?”Yes. Create a Custom HTML tag in GTM, paste the CustomerLabs tracking code, and set the trigger to Initialization - All Pages.
First-Party Domain Tracking
Section titled “First-Party Domain Tracking”What is First-Party Domain Tracking (1P)?
Section titled “What is First-Party Domain Tracking (1P)?”By default, the CustomerLabs tracking code sends data to io.v2.customerlabs.co — a third-party domain that can be blocked by ad blockers and browser privacy settings. First-Party Domain Tracking routes requests through a subdomain of your own domain (e.g., track.yoursite.com), bypassing those restrictions and setting cookies as first-party.
Why should I enable First-Party Domain Tracking?
Section titled “Why should I enable First-Party Domain Tracking?”- Prevents ad blockers from blocking CustomerLabs requests
- Sets cookies from your own domain, making them first-party (not blocked by ITP or browser privacy settings)
- Improves data completeness, which directly improves Event Match Quality for ad platforms
After setting up First-Party Domain Tracking, do I need to update my website?
Section titled “After setting up First-Party Domain Tracking, do I need to update my website?”Yes. After completing the 1P domain setup, you must replace the tracking code on your website with the updated snippet. The original code still points to the third-party domain — it does not automatically switch to your 1P domain.
Ad Blockers & Data Loss
Section titled “Ad Blockers & Data Loss”How do ad blockers affect CustomerLabs tracking?
Section titled “How do ad blockers affect CustomerLabs tracking?”Ad blockers target known third-party tracking domains. If First-Party Domain Tracking is not enabled, a portion of your traffic — typically users with ad blockers or strict browser privacy settings — will not be tracked client-side. Server-side events are unaffected.
How can I tell how much data I am losing to ad blockers?
Section titled “How can I tell how much data I am losing to ad blockers?”Compare the volume of client-side events with server-side events for the same event type (e.g., Purchase). A consistently lower client-side count suggests client-side suppression from ad blockers or browser privacy controls. Enabling First-Party Domain Tracking recovers this data.
Event Naming & Properties
Section titled “Event Naming & Properties”Are event names case-sensitive?
Section titled “Are event names case-sensitive?”Yes. Order_Placed and order_placed are treated as two different events in CustomerLabs. Use consistent lowercase naming with underscores across your implementation to avoid fragmented event data.
What properties should I send with events?
Section titled “What properties should I send with events?”At minimum, send the user identity fields (email, phone) using _cl.identify() and relevant event properties using the structured customProperties object. For e-commerce events (add-to-cart, purchase), include productProperties with product name, ID, price, and quantity.
Sending more user identifiers (email, phone, name, address) improves profile unification and Event Match Quality for Meta and Google Ads.
Unification
Section titled “Unification”What is event unification?
Section titled “What is event unification?”Unification is the process of matching server-side events with the corresponding client-side events for the same user. This is important because server-side events carry purchase and conversion data, while client-side events carry browser signals (fbp, fbc, GCLID) that ad platforms use for attribution.
When a server-side event is unified with a client-side event, the browser signals are merged into the final event payload sent to the destination — improving attribution accuracy.
How do I check my unification rate?
Section titled “How do I check my unification rate?”Navigate to Monitoring → Events Manager, select an event, and open the Unification Coverage tab. A low unification rate means server-side events are not being matched with their corresponding browser events, which reduces Event Match Quality for Meta and impacts attribution in Google Ads.
Why is my unification rate low?
Section titled “Why is my unification rate low?”Common causes:
- Users are not tracked client-side before the server-side event fires (e.g., user purchases on a page without the tracking code installed)
- The
customerlabs_user_idis not being passed from client-side to server-side events to enable matching - First-Party Domain Tracking is not enabled, and ad blockers are suppressing client-side events
Debugging
Section titled “Debugging”How do I verify events are firing correctly in real time?
Section titled “How do I verify events are firing correctly in real time?”Install the CustomerLabs Pixel Helper Chrome extension. It intercepts and displays all events fired to CustomerLabs in real time, showing event names, properties, user traits, and any missing or malformed fields.
My event count in CustomerLabs is lower than expected — how do I investigate?
Section titled “My event count in CustomerLabs is lower than expected — how do I investigate?”Check each stage of the pipeline separately:
- Source Logs (
Monitoring → Events Logs → Source Logs) — verify the event was received by CustomerLabs at the ingestion stage. - Workflow Logs (
Monitoring → Events Logs → Workflow Logs) — verify the event passed through the workflow without being filtered or dropped. - Destination Logs (
Monitoring → Events Logs → Destination Logs) — verify the event was successfully delivered to the destination.
A drop at any stage has a different root cause. See the event count verification guide for a step-by-step walkthrough.
What do the delivery statuses in Destination Logs mean?
Section titled “What do the delivery statuses in Destination Logs mean?”| Status | Meaning |
|---|---|
| Success | Event delivered successfully to the destination |
| Warning | Event sent in a non-standard format — may still be processed by the destination |
| Failure | Event was not delivered — inspect the error message for the cause |
How long are event logs retained?
Section titled “How long are event logs retained?”Logs are retained for 28 days. Each log query is limited to a maximum window of 3 consecutive days. For events older than 28 days, check the destination platform’s reporting directly.
Events are showing duplicate entries in the logs — what causes this?
Section titled “Events are showing duplicate entries in the logs — what causes this?”Duplicate events are caused by the tracking trigger firing more than once. Common causes include a GTM tag with multiple triggers, a tag set to fire on “All Elements” instead of a specific selector, or a backend webhook firing on retry. Check your GTM configuration or backend implementation for duplicate dispatches.