Once your tracking plan is finalized, you can start implementing it in NVECTA. This guide walks you through choosing an ingestion method, backfilling historical data, validating data quality, and shipping the plan safely from UAT to production, so teams can rely on reports with confidence.
NVECTA offers the following ingestion methods:
In most cases, starting with Client-side SDKs is a practical choice, especially if you have limited development resources, no existing data collection infrastructure, or no reliable way to capture clickstream data. Client-side SDKs are usually the fastest to set up and help teams get tracking live quickly.
However, client-side tracking can be affected by ad blockers and browser limitations. It can also become harder to maintain consistent metrics when tracking users across multiple platforms, such as a website and a mobile app.
To address this, many teams complement client-side tracking with Server-side SDKs. Server-side tracking is not impacted by ad blockers and provides more reliable and consistent data, particularly for critical events that represent business value.
A common and recommended approach is to start with Client-side SDKs for general user interactions, and gradually add high-value events, such as transactions, registrations, and account creation from the server side.
Click here to learn more in detail about each option’s trade-offs for reliability, latency, and control.
After choosing one or more ingestion methods, your team can start implementing the tracking plan in NVECTA. It’s recommended to first implement and validate tracking in a UAT environment. Once the data passes quality checks and behaves as expected, the same setup can be deployed to your production account.
At a minimum, your tracking plan should include a complete list of events (event name, attributes, and a clear definition of when each event fires), along with the required user properties.
You can use NVECTA’s tracking plan template to structure this information. If you choose to use your own template, make sure it clearly defines all events, attributes, and user properties.
If you’ve previously collected events and user data in another system (such as analytics platform or a CDP,), backfilling historical data helps make NVECTA reports meaningful from day one. A common recommendation is to backfill up to around 12 months of historical data, which is usually enough to capture trends and seasonality without adding unnecessary complexity to the migration.
For this, you can export the data and upload it to NVECTA as CSV files. NVECTA supports CSV imports for both users and events, refer to the guides on importing event data and importing user data for detailed requirements.