Migrating from client-side to server-side tracking

Transitioning from client-side pixels to server-side tracking requires careful planning and execution to maintain data continuity. A planned migration takes only a few hours and preserves your historical tracking data without creating duplicates or gaps.

Pre-migration planning

📘

Note

For a seamless migration, ensure that past user interactions are retained after migration by using the same cookie IDs to identify existing users.

Before starting your migration, audit your existing client-side implementation, including trigger conditions and data parameters. Prepare the following to ensure complete coverage on the server-side:

  • Map user identification methods: Identify how your client-side pixels identify users (cookie logic). Your server-side implementation must maintain the same cookie identifiers to preserve user journey continuity.

  • Schedule a maintenance window: Plan for a 2-4 hour migration window during your lowest traffic period. This minimizes the impact of any temporary overlap or tracking issues and allows time for validation.

  • Event diagnostics access: Set up debug pixels and check access to Event diagnostics in the Bloomreach dashboard to validate server-side implementation.

  • Rollback plan: Prepare scripts to quickly revert to client-side tracking if needed.

Migration sequence

Follow the general migration workflow for a smooth transition with minimal risk:

  1. Deploy server-side tracking: Deploy your server-side pixel implementation with debug pixels in parallel with existing client-side tracking.

  2. Validate data accuracy: Compare server-side events against client-side data to ensure accuracy.

  3. Switch to live pixels: Once validation confirms accurate tracking, update your server-side configuration to remove the debug flag to enable live pixels.

  4. Disable client-side pixels immediately: Remove or disable all client-side pixel code as soon as server-side tracking goes live.

  5. Monitor and verify (2-4 hours post-migration): Actively monitor your tracking data for the first few hours after migration using the Post-migration validation checklist.

🚧

Warning

Sending the same event from both client-side and server-side creates data quality issues that corrupt your analytics. Never run both tracking methods simultaneously for more than a few hours.

Post-migration validation checklist

Verify your migration succeeded by confirming:

  • Page view and Event volumes match pre-migration levels (with minor differences due to migration)

  • User identification remains consistent across the transition

  • No duplicate events appear in Event diagnostics

  • Event tracking maintains historical continuity