Usage measures and collection purposes

Opening an arcade page and visiting the location do not describe the same activity. For example, someone comparing travel options may read several pages without visiting every arcade. Detail views indicate interest, directions indicate travel intent and verified visits describe an on-site action.

flowchart TD
    accTitle: Separating purpose-specific metrics from visits
    accDescr: Views and directions events are aggregated without personal identifiers; verified visits are aggregated from separate domain records.
    E[Views and directions] --> A[Purpose-specific analytics events]
    A --> S[Server aggregation]
    V[Verified visit records] --> T[Visit metric aggregation]
    S --> R[Results by permission]
    T --> R

These distinctions help improve the service without requiring a person-by-person movement history. Purpose-specific analytics events do not store IP addresses, user agents or user identifiers. Results are divided into public basic measures and detailed operational measures.

Analytics events and visit statistics

Detail views and directions are predefined append-only events, aggregated by the server. The API restricts event types and related arcades rather than exposing internal collections for browsers to populate arbitrarily.

sequenceDiagram
    accTitle: Reading details and recording metrics
    accDescr: The detail API reads public arcade data, attempts to record a view event, and returns the details.
    participant W as User request
    participant A as Detail API
    participant D as Storage
    W->>A: Read arcade details
    A->>D: Read public arcade
    D-->>A: Detail data
    A->>D: Attempt to record view event
    A-->>W: Detail response

Visit totals and distinct visitor counts come from the existing verified-visit domain under its permitted conditions. They are not computed by attaching user IDs to anonymous view events. A visit feature can require an account without every unrelated analytics event needing identification.

Public statistics and operational metrics

Basic metrics are public. Detailed operational measures, including directions, verified visits and distinct visitors, are available to responsible arcade accounts and authorized staff. The query API checks the actor’s permission for the target arcade rather than relying on hidden interface elements.

flowchart TD
    accTitle: Access boundaries for metric responses
    accDescr: After checking that the venue is currently public, return basic metrics separately from operational metrics requiring permission.
    Q[Metric request] --> P[Check venue visibility policy]
    P --> B[Public basic metrics]
    P --> O[Check management permission]
    O --> D[Protected detailed metrics]

Aggregation also applies arcade visibility rules, preventing statistics from revealing places unavailable through their detail pages. Visits and rankings retain their own storage while sharing the rules for which locations may be public.

Interpreting metrics and collection failures

Purpose-specific aggregation provides usage information without building personal tracking histories. A failed analytics write does not block a valid detail response: collecting a metric should not stop someone reading the page they requested.

A view count is not a unique-user count, and repeated requests and failed writes affect it. Verified-visit totals also depend on that feature’s validation conditions. Each number needs to be read alongside the activity and collection scope that produced it.

Related articles and sources: Engineering history