Event Collection Controls & Heartbeats

Flash Analytics supports dashboard-managed event collection rules and heartbeat-based session tracking. Use them to reduce unnecessary event volume, limit sensitive properties, and keep active-session reporting accurate when users stay engaged without firing product events.

Event whitelisting

Event whitelisting controls which events your application sends to Flash Analytics. Rules live in the project configuration, so teams can change collection behaviour without releasing a new mobile or web build.

Depending on project configuration, you can:

• Allow all events
• Allow only selected events
• Block specific events or patterns
• Allow or remove selected event properties
• Drop events when property conditions match
• Turn collection rules on or off
• Apply project-wide property restrictions

Collection controls are available for eligible projects. Contact the Flash Analytics team to confirm access for your plan and client library.

Default behaviour

When collection filtering is active:

• Allowed events are queued and sent normally
• Supported SDKs discard blocked events before send when current rules are available
• Events rejected by collection controls are not stored or counted toward event volume
• Rejected analytics events do not create or extend sessions
• The backend validates incoming events as the final enforcement layer

Where supported, client libraries filter events before they are sent, reducing unnecessary network traffic and backend processing. The backend remains the final enforcement layer for every client, including older or custom integrations and cases where current rules are not yet available locally.

Allow-all and whitelist-only

Flash Analytics supports two collection modes.

Event patterns

You can allow or block exact event names, or use a limited wildcard. Wildcard support is trailing * only (for example checkout.*).

Example allow list:

• login
• purchase
• checkout.* — matches checkout.started, checkout.completed, checkout.failed

Example block list:

• debug.*
• internal_test

Banking and insurance examples

Collection controls are especially useful in regulated applications, where teams need useful product analytics without sending unnecessary customer identifiers or internal operational data.

Banking

A banking application could allow customer-journey events such as:

account.login
account.balance_viewed
fund_transfer.started
fund_transfer.completed
beneficiary.added
loan.application_started
loan.application_submitted
card.block_requested

Development and internal operational events could be blocked:

debug.*
internal_api_retry
test_transaction
developer_console_opened
mock_bank_response

For fund_transfer.completed, a bank might keep onlytransferType, amountBand, currency, and destinationBank. Fields such as an account number, beneficiary phone number, or internal debug reference can be removed before the event leaves the client.

A drop filter could also exclude employee-generated test transfers whenenvironment equals staging anduserType equals employee.

Insurance

An insurance application could allow journey events such as:

quote.started
quote.completed
policy.viewed
policy.purchased
claim.started
claim.document_uploaded
claim.submitted
renewal.offer_viewed
renewal.completed

Internal or test-only events could be blocked:

ocr.raw_response
internal_risk_score
debug_document_scan
test_claim
underwriting_engine_trace

For quote.completed, an insurer might keepproductType, premiumBand,coverageType, and vehicleAgeBand. Direct identifiers and internal underwriting values can be removed before send.

A drop filter could exclude internal test claims whenenvironment equals test andclaimSource equals internal.

Property filtering

Rules can control which event properties are sent. Allowed properties are kept; others are removed before the event leaves the client. Project-wide blocked properties can also be removed from all applicable events.

This is useful when an event is valuable for analysis, but some fields are unnecessary or sensitive and should never leave the device.

Property-based drop filters

You can drop an entire event when its properties match configured conditions. All configured conditions must match for the event to be dropped.

Example: drop policy.purchased when environment equals test and salesChannel equals internal.

Automatic collection configuration

Supported SDKs receive project collection settings automatically during initialization. Integration details may differ by platform and SDK version, but applications do not need to manage event rules themselves.

During startup, tracking continues while collection settings become available. The backend still applies the project rules, so events rejected by collection controls are not stored or counted toward event volume.

import { FlashAnalytics } from "@flash-analytics/sdk";

const analytics = new FlashAnalytics({
  appId: "YOUR_APP_ID",
});

analytics.track("checkout.completed", {
  productType: "standard",
  premiumBand: "5000_10000",
  coverageType: "full",
});

Before an event is queued or sent, supported SDKs apply:

• Event whitelist rules
• Event block rules
• Property allowlists and blocklists
• Property-based drop filters
• Project-defined batching defaults, where supported

Event batching

The SDK groups events into small batches to reduce network requests. Events are typically sent when the batch reaches its configured size or when the flush interval expires. Batch size and flush interval may be managed from the dashboard.

Local SDK batching settings take priority over dashboard defaults when both are set.

Blocked events are filtered before batching. They are never added to the batch queue. See the Event Batching guide for delivery details.

Session heartbeats

Session heartbeat support is available for eligible projects and supported client libraries. A heartbeat confirms that a user is still active even when the app has not generated a normal analytics event for a while — for example while reading long content, filling a form, or waiting on a verification screen.

While the application determines that the user is still active, a supported client sends heartbeat signals at the configured cadence. This can keep the session active even when the user is not generating any whitelisted product events. An accepted heartbeat can:

• Confirm the session is still active
• Refresh the session activity timestamp
• Prevent premature session expiry during quiet activity
• Improve session-duration accuracy
• Count as heartbeat activity for usage measurement

When heartbeats stop and no other accepted activity arrives, the session ends after the configured inactivity timeout. A blocked analytics event does not act as a heartbeat and does not extend the session.

Heartbeat signals are accepted service events, not blocked analytics events. Each accepted heartbeat is counted toward heartbeat usage and may contribute to the applicable event or request allowance for the project. They do not appear as normal business events in analytics reports unless explicitly configured that way. Total heartbeat usage depends on how long users remain active and the cadence used by the supported client library. Event-volume and API read limits can vary by plan, project, and client library. Contact the Flash Analytics team to confirm heartbeat availability and applicable limits. See Sessions for the base session model.

Plan availability

Event whitelisting, property filtering, session heartbeats, event-volume limits, and API read limits may depend on the active Flash Analytics plan and client library. For eligible projects, available controls are managed through the dashboard. Standard event tracking continues for projects where collection controls are not enabled.

For private deployments, custom plans, regulated environments, or specialised SDK integrations, contact the Flash Analytics team to confirm availability and enablement.

Client-library support

Automatic collection configuration is available in supported Flash Analytics client libraries. Support may differ across:

• JavaScript / browser
• Next.js
• React Native
• Android
• iOS
• Server-side libraries

Some older or specialised libraries may not apply collection rules locally. Events from those clients are still validated by the backend when server-side controls are enabled, but they may use more network bandwidth before rejection.

Before enabling whitelist-only mode, confirm that the client library and version used by your application support automatic collection configuration. For an undocumented, private, or custom integration, contact Flash Analytics with the platform, package name, SDK version, and whether heartbeat support is required. The team can confirm compatibility and arrange enablement where applicable.

Implementation guidance

We appreciate the effort required to keep analytics clean, secure, and reliable across complex applications. Event collection controls are designed to reduce unnecessary data, protect sensitive properties, and let teams adjust collection without frequent application releases.

For banking, insurance, or other regulated use cases, review the event whitelist, property rules, client-library support, heartbeat behaviour, and plan limits with the Flash Analytics team before enabling whitelist-only collection in production.

Related guides