Traffic analytics: what the numbers support

What Echo measures#

Open /analytics for the aggregate view. Echo groups accepted production events by site and selected date range after removing internal paths, staff, test, QA, and synthetic traffic through the shared exclusion layer. echo-cli analytics 30 returns the bounded underlying web and mobile event projections without user or anonymous identifiers; echo-cli chat-latency 30 and Echo Desktop's Chat latency page return only production per-site response aggregates.

For first-party web events, an actor is user_id when present and anonymous_id otherwise. Sessions use session_id. Page, event, engagement, referrer, acquisition, lifecycle, revenue, and retention values therefore describe measured identifiers and sessions—not a census of people.

Read chat response latency#

Echo joins no customer identity into this view. It reduces chat_assistant_response and chat_assistant_response_server events by site after the same production exclusions used by the dashboard, then returns nearest-rank P50 and P95 values in milliseconds. CLI and Desktop inspect at most the latest 5,000 matching rows in the selected window and disclose only site names, client/server row counts, and aggregate timings.

client_samples and server_samples count accepted response event rows. A blank, negative, or non-numeric timing is ignored by that metric's percentile calculation, so a row count is context for coverage rather than a guarantee that every percentile has the same denominator.

echo-cli chat-latency 7

Configure a deployment#

Echo contains no built-in customer, site, application, or host. A single-site web deployment sets the public collector URL, site id, site name, and base URL. A multi-site deployment supplies WEB_ANALYTICS_SITES_JSON; each entry declares its canonical id, display name, hosts, optional aliases, and collector URL. MOBILE_ANALYTICS_APPS_JSON similarly declares every iOS, Android, or macOS application, its analytics backend, canonical and legacy ids, and optional GA4 identifiers. These registries authorize collector requests and define the web sites and mobile apps shown in the dashboard.

UMAMI_AUDIT_TARGETS_JSON declares the public pages whose Umami installation Echo audits. When it is absent, Echo derives targets from NEXT_PUBLIC_UMAMI_DOMAINS. Connected Umami accounts can still add their managed sites to the report. CORS_ALLOWED_ORIGINS declares external dashboard clients; Echo also allows its own NEXT_PUBLIC_SITE_URL origin. PRODUCT_ANALYTICS_SITE_ID and the two PRODUCT_*_SNAPSHOT_EVENT_NAME values bind optional product snapshot imports; ANALYTICS_EXCLUDED_* lists hold deployment-specific test events, paths, hosts, and identities.

NEXT_PUBLIC_SITE_URL=https://echo.example.com
NEXT_PUBLIC_BASE_URL=https://echo.example.com
NEXT_PUBLIC_ECHO_ANALYTICS_COLLECTOR_URL=https://echo.example.com/api/analytics/web/collect
NEXT_PUBLIC_WEB_ANALYTICS_SITE_ID=my-product
NEXT_PUBLIC_WEB_ANALYTICS_SITE_NAME=My Product
WEB_ANALYTICS_SITES_JSON='[{"id":"my-product","name":"My Product","hosts":["www.example.com"],"aliases":[],"collectorUrl":"https://echo.example.com/api/analytics/web/collect"}]'
MOBILE_ANALYTICS_APPS_JSON='[{"id":"my-product-ios","name":"My Product iOS","platform":"ios","analyticsBackend":"first_party","firstPartyAppId":"my-product-ios","legacyFirstPartyAppIds":[],"collectorUrl":"https://echo.example.com/api/analytics/mobile/collect"}]'
UMAMI_AUDIT_TARGETS_JSON='["https://www.example.com"]'
CORS_ALLOWED_ORIGINS=https://app.example.com
PRODUCT_ANALYTICS_SITE_ID=my-product
PRODUCT_ANALYTICS_SNAPSHOT_EVENT_NAME=product_admin_analytics_snapshot
PRODUCT_CONVERSATION_SNAPSHOT_EVENT_NAME=product_admin_conversation_snapshot
ANALYTICS_EXCLUDED_PATHS='["/internal/test-page"]'

Read the web funnel exactly#

Echo counts distinct actors with page_view as landing users, identity events as identified users, activation events as activated users, and purchase events as purchase users. The four counts are computed independently inside the selected window; they are not automatically restricted to the same ordered cohort.

landing-to-identity = identified users / landing users
identity-to-activation = activated users / identified users
activation-to-purchase = purchase users / activated users

Worked example#

Suppose a 30-day site report shows 10,000 landing users, 2,500 identified users, 1,000 activated users, and 100 purchase users. Echo displays 25% landing-to-identity, 40% identity-to-activation, and 10% activation-to-purchase.

The defensible conclusion is: the largest observed count gap is between landing and identity, while the lowest displayed stage ratio is activation-to-purchase. First verify identity and purchase event coverage, then split the report by acquisition source and landing page. If coverage is sound, test one concrete landing or offer change and evaluate activation, purchase, retention, and revenue on assigned cohorts.

The report does not establish that the landing page caused the gap, that 90% of activated people abandoned purchase, or that a redesign will improve revenue. Those claims require ordered actor-level cohorts or an experiment.

Questions the data can answer#

• Is measured traffic rising or falling versus the previous matching window, and is the change concentrated in one site, source, landing page, or event?
• Which sources bring actors who activate, purchase, return, and produce net revenue—not merely page views?
• Which pages combine substantial reach with low engagement or weak later-stage outcomes and deserve an instrumentation check or experiment?
• At which measured stage does the largest count or ratio change appear: landing, identity, activation, paywall, checkout, trial, purchase, renewal, cancel, or refund?
• Do eligible cohorts return on D1, D7, and D30, and does acquisition quality persist after the first session?
• Is paid traffic linked to first-party outcomes strongly enough to discuss CAC, ROAS, and payback, or is attribution coverage the finding?
• Are missing events, non-reporting sites, contract failures, exclusion mistakes, or identifier breaks making every business conclusion premature?

Claims the data cannot make alone#

• Traffic movement does not identify its cause. Seasonality, releases, outages, campaign mix, consent, blockers, and instrumentation can move the same number.
• A referrer or UTM association is attribution evidence, not proof that the channel caused the outcome. Use a holdout or randomized experiment for incrementality.
• Anonymous and identified ids do not guarantee one stable person across devices, browsers, consent changes, or identity transitions.
• High engagement does not prove satisfaction, intent, accessibility, or product value; pair it with activation, retention, revenue, quality, and support signals.
• Umami supplies visitors, visits, pageviews, bounces, duration, pages, and events, but Echo sets identified, activated, purchased, and revenue funnel values to zero for an Umami-only source. Zero there means unavailable, not necessarily no outcome.
• Small eligible cohorts and incomplete contracts do not support ranking sources or variants. Show counts with every rate and name missing data.

Decision checklist#

1. Choose the site, date range, comparison window, and business question before reading a metric.
2. Check reporting coverage, exclusions, contract failures, identifier continuity, and linked attribution.
3. Read counts before rates and show every denominator, especially retention eligibility.
4. Segment by source and landing page, then compare activation, purchase, retention, net revenue, and quality.
5. Write one observation, one competing explanation, and one measurement or experiment that could separate them.
6. Change a product or budget only after the outcome metric and guardrails support it.