> ## Documentation Index > Fetch the complete documentation index at: https://docs.paraminternationalltd.com/llms.txt > Use this file to discover all available pages before exploring further. # Data Control and Quality > Keep your Twinalyze data clean by detecting duplicate events, missing events, wrong event names, invalid properties, bots, test traffic, and unwanted traffic. 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 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** Avoid sending the same event from both auto tracking and manual tracking. Use values like `eventId`, `orderId`, `sessionId`, or `screenId` for important events. Review events that suddenly increase without a real product or marketing change. Test signup, checkout, payment, and purchase events carefully before release. **Recommended duplicate-safe event** ```json theme={null} { "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. ```txt theme={null} 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** ```txt theme={null} 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** ```json theme={null} { "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 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 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. ```json theme={null} { "eventName": "checkout_started", "properties": { "environment": "staging", "isInternalUser": true, "testerRole": "qa" } } ``` 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 Add validation for signup, form submit, checkout, payment, and purchase events. Review traffic sources, referrers, campaigns, IP patterns, and device 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. ```json theme={null} { "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 Troubleshooting Go to troubleshooting if have any problem. Next ›