Data Control and Quality

Clean data is the foundation of accurate analytics. Twinalyze helps you find tracking issues early, keep reports reliable, and make sure your users, events, funnels, retention, campaigns, and Ask AI insights are based on trusted data.

Quality control map

Data quality overview

These are the most common data quality issues that can affect reports, funnels, retention, campaigns, and user insights.

Issue	What can go wrong	Business impact
Duplicate Events Same action tracked twice	The same event is sent more than once for one user action.	Inflated counts, wrong funnels, and inaccurate revenue or engagement reports.
Missing Events Expected event not received	Important actions like signup, checkout, purchase, or screen view are not tracked.	Broken funnels, incomplete journeys, and incorrect conversion analysis.
Wrong Event Names Same action, different names	One action is tracked with multiple names such as `AddToCart` , `add_cart` , or `add_to_cart` .	Split reports, confusing analysis, and unreliable filters.
Invalid Properties Missing or wrong values	Required properties are missing, inconsistent, or sent in the wrong data type.	Bad segments, wrong cohorts, and unreliable reports.
Bot & Unwanted Traffic Fake or non-human activity	Crawlers, scrapers, spam, test users, or internal users are mixed with real users.	Fake users, wrong sessions, and misleading product decisions.

Data quality checks

Duplicate Events
Missing Events
Wrong Event Names
Invalid Properties

Duplicate events happen when the same user action is tracked more than once.

Duplicate events can increase event counts and create incorrect reports, funnels, campaign results, and revenue metrics.

Common examples

Common duplicate event examples

These issues usually happen when the same action is tracked more than once.

Example	Why it is a problem
`button_clicked` fires twice	One click appears as two actions.
`screen_viewed` fires repeatedly	Screen views become inflated.
Auto + manual tracking both send same event	Reports count the same action twice.

How to prevent duplicate events

Use one tracking method

Avoid sending the same event from both auto tracking and manual tracking.

Use unique identifiers

Use values like eventId, orderId, sessionId, or screenId for important events.

Check sudden spikes

Review events that suddenly increase without a real product or marketing change.

Test critical events

Test signup, checkout, payment, and purchase events carefully before release.

Recommended duplicate-safe event

{
  "eventName": "purchase_completed",
  "eventId": "evt_10293",
  "orderId": "ORD_98765",
  "userId": "user_123",
  "sessionId": "session_789",
  "properties": {
    "amount": 2499,
    "currency": "INR",
    "itemCount": 3
  }
}

Missing events happen when an expected user action is not tracked.

Missing events usually happen because of SDK setup issues, wrong trigger conditions, network failures, or code paths where tracking was not added.

Missing event examples

Missing event examples

These examples show important actions where tracking may be missing.

Expected action	Missing event
User opens checkout	`checkout_started` is not received
User completes signup	`signup_completed` is missing
Screen opens	`screen_viewed` is not tracked
Notification is shown	`notification_received` is missing
Payment fails	`payment_failed` is not received

How to detect missing events

How to detect missing events

Use these checks to confirm that important events are tracked correctly.

Check	What to verify
Event flow	Expected events are received in the correct order.
Platform coverage	Web, Android, iOS, Flutter, and React Native send the same important events.
Critical actions	Signup, checkout, payment, and purchase are always tracked.
SDK health	SDK is initialized before events are sent.

Create a small test journey and verify every expected event from start to finish.

page_view
product_viewed
add_to_cart
checkout_started
payment_started
purchase_completed

Wrong event names make analysis difficult because the same action appears as multiple different events.Recommended format

add_to_cart
checkout_started
payment_failed
purchase_completed
screen_viewed
notification_clicked

Event naming rules

Event naming rules

Follow one naming style across all platforms to avoid split reports.

Rule	Recommended
Case style	Use lowercase.
Word separator	Use underscore.
Event meaning	Use action-based names.
Platform consistency	Use the same event name across Web, Android, and iOS.

Do not create multiple names for the same user action. It will split reports and reduce data accuracy.

Invalid properties happen when event data is missing, wrongly typed, or inconsistent.Common property issues

Common property issues

These property issues can break filters, reports, cohorts, and segmentation.

Issue	Example
Wrong data type	`price` sent as text instead of number
Missing required value	`currency` missing from purchase event
User mismatch	`userId` missing after login
Inconsistent value	`country` sent as `India`, `IN`, and `india`
Platform mismatch	`screenName` differs across platforms

Recommended property format

{
  "eventName": "add_to_cart",
  "properties": {
    "productId": "PRD_1001",
    "productName": "Gold Hair Pin",
    "category": "Hair Accessories",
    "price": 499,
    "currency": "INR",
    "quantity": 1
  }
}

Property validation checklist

Property validation checklist

Validate important properties before using them in filters, cohorts, and reports.

Property check	Example
Required value exists	`productId` should not be empty.
Correct data type	`price` should be a number.
Consistent value	`currency` should be `INR`, not `inr` or `Rs`.
Platform match	Web and app should send similar property names.

Keep property names stable. Changing property names later can break filters, cohorts, and saved reports.

Common unwanted traffic types

Bots

Bots are automated systems that visit your website or app without real user intent.Common examples:

Search engine crawlers
Scrapers
Automated testing tools
Headless browser traffic
Fake traffic generators

Bot indicators

These signals help identify traffic that may not represent real users.

Signal	Example
Very high event frequency	Hundreds of events in a short time
No real interaction pattern	Page views without clicks or meaningful actions
Suspicious user agent	Headless browser, crawler, or automation tool
Repeated IP/device pattern	Same source creating many sessions
Invalid session behavior	Session duration too short or repetitive

Bot traffic can increase page views, sessions, users, and event counts without real user activity.

Internal Traffic

Internal traffic comes from your own team, developers, QA testers, support team, or admin users.This traffic is useful for testing, but it should not affect production analytics.Common examples:

Developer testing SDK events
QA testing checkout or signup flow
Admin team opening dashboard repeatedly
Internal users using staging or demo builds

Use properties like environment: "development" or environment: "staging" to separate test data from production data.

{
  "eventName": "checkout_started",
  "properties": {
    "environment": "staging",
    "isInternalUser": true,
    "testerRole": "qa"
  }
}

Spam Traffic

Spam traffic is fake or low-quality traffic created to pollute analytics.Common examples:

Repeated fake signups
Fake form submissions
Invalid referral traffic
Suspicious campaign traffic
Repeated events from the same unknown source

Validate important events

Add validation for signup, form submit, checkout, payment, and purchase events.

Check suspicious sources

Review traffic sources, referrers, campaigns, IP patterns, and device patterns.

Block invalid patterns

Filter traffic from known bot sources, invalid user agents, or suspicious repeated sessions.

Recommended filtering rules

Bot and traffic filtering checklist

Use multiple signals to separate real users from unwanted traffic.

Check	What to detect	Recommended action
User agent	Headless browsers, crawlers, automation tools	Mark as bot or exclude
Event frequency	Too many events in a short time	Flag as suspicious
Session pattern	Very short or repeated sessions	Review or exclude
Environment	`development`, `staging`, `debug`	Exclude from production reports
Internal users	Team, QA, admin, developer traffic	Mark as internal

Do not rely on only one signal to detect bots. Use multiple signals like user agent, IP pattern, event frequency, session behavior, and environment.

Suggested event structure for traffic quality

Send traffic-related properties with important events so Twinalyze can detect suspicious activity more accurately.

{
  "eventName": "page_view",
  "userId": "user_123",
  "deviceId": "device_456",
  "sessionId": "session_789",
  "properties": {
    "environment": "production",
    "platform": "web",
    "userAgent": "Mozilla/5.0...",
    "referrer": "https://google.com",
    "isInternalUser": false,
    "isTestUser": false,
    "source": "organic",
    "campaign": "summer_sale"
  }
}

Before going live

Final quality checklist

Verify your tracking before launch

Event names are consistent

Use one clear name for each action across Web, Android, iOS, Flutter, and React Native.

Critical events are tested

Test signup, checkout, payment, purchase, notification, and screen events.

Properties are valid

Required properties should be present, correctly typed, and consistent.

Test traffic is separated

Use environment, internal user, and test user properties to protect production reports.

‹Previous Go to troubleshooting if have any problem.Next›

GETTING STARTED

ORGANIZATION & PROJECT

DATA

ADMINSTRATION

Data Control and Quality

Quality control map

Data quality checks

Common unwanted traffic types

Recommended filtering rules

Suggested event structure for traffic quality

Before going live