We need a tracking plan

Data requirements move quickly within a fast-growing organization, and if you have any hope of staying on top of what's being tracked, why and how, you need one central source of truth for tracking. This takes the form of a tracking plan, which can be a simple Excel spreadsheet or Google Sheet.

It should list every important tracking event that your organization values, alongside when those events are triggered, and the different properties each of those events. For example when someone signs up, you'll have their name and email, which might need to be passed to your email provider.

It's also helpful to show visually where these events take place, as that will (literally) align everyone on the same page, and decrease the chance of mistakes. This is a living document which should get updated every time your tracking needs change. It should be shared across the whole team, so anyone looking at analytics can easily see what each event name refers to, and identify issues, bugs and gaps in tracking.

It helps to think about your tracking plan from the perspective of the user journey. What does the marketing and sales funnel look like? What happens in each stage from first time visitor to long time customer? Thinking of events in terms of the marketing funnel helps ensure you haven't forgotten anything important.

Analytics is a case of garbage in, garbage out. If you don't have a consistent naming convention, you'll struggle to do accurate analysis afterwards, and future team members will struggle even more without your context.

The most useful framework I've found for naming is Segment's 'Object-Action'. You list the actual objects that are being acted upon (these can map to actual objects in the code or rows in your database) and then describe the action being taken. So for example it would be `User Sign Up` rather than `Sign Up`.

You should also use consistent spacing, spelling and capitalization, as `User Sign Up`, `user sign up`, `User Signup`, `user_sign_up` and `user-sign-up` are all counted as different events.

Tracking events that occur as a user browses your website is fairly straightforward. You add some JavaScript tracking code via a Tag Manager or directly on the website, and it fires whenever that action is completed. However if the action takes place when the user isn't on the website, it needs to occur server-side.

For example, if the sales team updates a contact record in your CRM to say that a user has booked a demo, you have no guarantee the user is active on your website. Instead you send a hit to Google Analytics' server to register the event, either via custom code, your tag manager (if it has this capability) or an API service like Zapier.

In this case, your server doesn't have access to browser cookies, which are usually used to track the ID of each user. So instead you need to have a way of passing a unique user ID (UUID) that is stored in the CRM alongside the user record. Best practice is to assign that UUID on the user's first visit to the website and store it in a cookie. Then when the user submits their email for a demo request, makes a purchase, or signs up for your product, it comes along for the ride in a hidden field - it's part of the form, but the user can't see it. You would use a similar system to capture the users' marketing source (UTM parameters) and pass that to the CRM as well.