An event fires. It records a purchase. The purchase amount should be $99. But it records $990. A decimal point is wrong. That's bad data. An event fires. It should capture a product category. But it captures nothing. That's missing data. Bad data skews your analytics. Wrong conclusions follow. You make decisions based on wrong numbers. Data quality is critical. Every event must capture accurate data. Every parameter must have the right value. This requires careful setup and ongoing monitoring.
This article explains how to ensure event parameters capture quality data.
Why Data Quality Matters
Analytics is only useful if the data is accurate. You analyze conversion rates. You optimize based on the numbers. But if conversion numbers are wrong, your optimization is wrong. You might optimize the wrong thing. You might miss opportunities.
Bad data compounds. A small error in one event becomes a big error in aggregate. If 10 percent of purchase events have wrong amounts, your revenue numbers are off by 10 percent. That's a significant error in business decisions.
Data quality builds trust. Your team trusts analytics when numbers are accurate. They make decisions based on it. If data is unreliable, they stop trusting. They stop using analytics.
Define Event Parameters Precisely
Before creating an event, define what each parameter should contain. Parameter name. Parameter description. Parameter data type. Expected value range. Where the value comes from.
A purchase amount parameter should be clearly defined. Is it the total including tax and shipping. Or just product cost. Is it in cents or dollars. Is it a string or number. Define this precisely. Implementation depends on it.
Document every parameter. Documenting prevents confusion. A developer implementing the event knows exactly what to capture. An analyst reading the data knows what it represents.
Capture Data From the Right Source
Data quality depends on capturing from the right source. A purchase amount should come from your order processing system. Not an estimate. Not a user input. The actual confirmed amount.
A product category should come from your product database. Not from what the user typed. Not from a guess. The authoritative category.
Get data as close to the source as possible. Real transaction systems know the real amounts. Real databases know the real categorization. Pull from there. Don't calculate or estimate.
Validate Data Before Events Fire
Validate data before you send it to analytics. Check that the purchase amount is a number. Check that it's positive. Check that product ID exists.
Validation catches errors before they become analytics problems. A developer makes a mistake. Validation catches it. The data never reaches analytics. The event fires with good data.
Common validations include type checking (is it a string, number, or date), range checking (is it within expected values), and existence checking (does the referenced item exist).
Use Consistent Parameter Names
Parameter naming matters. If one event calls a parameter "amount" and another calls it "purchase_amount", your reports treat them as different parameters. You can't compare them.
Create a naming standard. All monetary values use the suffix "_amount". All IDs use the suffix "_id". All counts use the suffix "_count". Apply this standard consistently.
Once you name a parameter, don't change it. Changing parameter names splits your data. Old data is under the old name. New data is under the new name. Reports show split data. Get naming right before you deploy.
Handle Edge Cases and Missing Data
Some data is hard to capture. Offline transactions. Legacy system transactions. Incomplete user information. How do you handle missing data.
Never send events with missing critical parameters. If you can't get the purchase amount, don't fire the purchase event. Send the event only when you have complete data.
For optional data, use null or empty string consistently. Don't use "unknown" in one place and "N/A" in another. Consistent handling of missing data makes analysis easier.
Monitor Data Quality Over Time
Data quality degrades over time. Integrations break. Systems change. What worked last month might break this month. Monitor continuously.
Check for unexpected patterns. Null values where they shouldn't be. Outliers in amounts. Missing parameters. Set up alerts. If something looks wrong, investigate.
Review data quality reports regularly. Most analytics platforms have data quality reports. Use them. Catch problems early.
Frequently asked questions
How do we test if event parameters are capturing correctly?
Use real-time reports. Perform the action. Watch the report. Check that the event appears with the right parameters and values. Use browser developer tools. Inspect the data before it sends to analytics. Verify it matches expectations. With WEMASY's website builder, you can set this up directly on your website.
What if a parameter value is always empty?
The data isn't being captured. Check your implementation. Is the parameter configured correctly. Is the data available when the event fires. Is there a timing issue. Debug the source. Don't send empty data. Fix the root cause.
Can we rename a parameter after data is collected?
Technically yes but don't. Old data stays under the old name. New data goes under the new name. Your reports show split data. Get the name right from the start. If you must rename, plan for the data split.
How do we handle currency in event parameters?
Capture the numeric amount and the currency code separately. Amount in a parameter like "purchase_amount". Currency in a parameter like "currency_code" with values like "USD" or "EUR". This lets you analyze across currencies.
Should we store raw data or formatted data in parameters?
Store raw data. Amounts in cents not dollars. Timestamps in ISO format not human readable. Formatted data is harder to analyze and compare. Raw data is more flexible. Format it in reports if needed.
What's a reasonable error rate for event data?
Zero is the goal. But in practice, less than 1 percent is acceptable. Some edge cases will have issues. Legacy systems might not have data. But if error rates exceed 1-2 percent, investigate and fix the root cause.