Test your integration

The Testing console streams every event your SDK sends, live, with the numbers that prove an integration works — arrival lag, SDK version, device info, ATT state. Fire an event from your test device and watch it land in seconds.

Open the console

In the advertiser panel: reflect.cloud → Apps → Testing console. It connects over WebSocket (falls back to 2.5 s polling automatically) and shows the most recent events first, flashing green as they arrive. Nothing to configure — if your SDK is initialized with the right app key, events appear within seconds of being sent.

Read the Lag column first

Lag is device event time → server arrival — the single number that separates a healthy integration from a broken one:

• ≤ 5 s — healthy. This is what a correct integration looks like, including on the very first launch after install.
• ≤ 30 s — fine; the periodic flush window.
• ≤ 5 m — slow: usually a device with poor connectivity, or an event fired right before the app was backgrounded on an old SDK.
• > 5 m — broken: the batch sat in the durable queue. On iOS, update to unity-2.4.4 / ReflectCore 1.1.4 or newer — older cores could hold first-session events until the app's second open.

A ⏱ badge next to the lag means the device's clock was implausible and the server clamped the event timestamp — the lag shown is approximate, and the device clock is the thing to distrust, not the SDK.

Follow one device

Click 📌 on any row to pin that device: the stream narrows to its install_uuid (server-side, not just a visual filter), and a banner shows the device's profile — model, OS, SDK version, app version, ATT state. This is how you watch a single test phone in the middle of production traffic. Unpin from the banner; copy id puts the install_uuid on your clipboard for terminal use.

Filter the stream

• Type chips — one click isolates Installs, Sessions, Revenue, or Crashes (with live counts).
• App selector — scope to one app; every app that has produced an event in the buffer is listed.
• Free-text filter — matches event name, device model, SDK version, session, country, partner, install_uuid, user_id.

Row details

Click any row for the full picture: event id, device time vs arrival, session, attribution (partner or organic), transaction and revenue, environment, ATT, rooted flag. Debug attribution → jumps to the attribution debugger pre-filtered to that install.

A first-install test, end to end

1. Delete the app from the test device (iOS: Delete App, not Offload; Android: disable backup first — adb shell bmgr enable false — or the install state survives reinstall).
2. Open the Testing console, ready to watch. Optionally click your tracking link on the device first to test attribution.
3. Install and launch. Within seconds you should see app_install, app_first_open, session_start, app_open — green lag, correct sdk_version, your app version.
4. Pin the device, then exercise your integration: sign-up, purchase, custom events — each should land with single-digit lag.
5. Attribution note: install-to-click times under 60 seconds are treated as suspicious by fraud filtering — wait at least a minute between clicking your test link and installing.

Nothing arriving?

1. The app key in your SDK config must match the app in Settings → Apps — the console shows the whole tenant, but a wrong key means the server rejects the batch entirely.
2. Fully relaunch the app after adding the SDK; check the device has network.
3. Enable SDK logging and look for [Reflect] lines — the SDK prints every send and every response.
4. On iOS, confirm your build uses ReflectCore 1.1.4+: older cores combined with a declared tracking domain could silence devices until ATT was authorized. See the changelog.
5. Still stuck — the quickstart walks the whole setup from zero, and the debug overlay shows what the SDK is collecting on-device.