Verify the first identification event

After completing the SDK integration, trigger a real identification in the test environment and confirm the event in the dashboard.

Initiate a test request

1. Launch a test website or app.
2. Open the test page or integration point where the SDK is installed.
3. Perform an identification call.
4. Submit the GeeToken returned by the SDK to your test backend.
5. Record the request_id and device_id returned by the server-side query.

When verifying for the first time, it is recommended to initiate only a small number of requests at a time to avoid repeated calls interfering with troubleshooting.

After the test is completed, do not output the complete identification results to the client production log for a long time.

Query on the event page

1. Return to the Geelab console.
2. Enter Events in the left navigation.
3. Select the application you just created and the corresponding Region.
4. Set the time range to include the time of the test request.
5. Open Advanced Filtering and select Request ID.
6. Enter what you just recorded request_id, the operator remains asis.
7. Apply filters and view query results.

If the Request ID is not recorded, it is possible to view the latest events within a shorter time range, but using the Request ID to query more accurately is more reliable.

Check Request ID and Device ID

Check in the event list or event details:

• Whether the Request ID is consistent with the client record.
• Whether the Device ID exists.
• Whether the event belongs to the correct application, region and integrations.
• Whether the event time is consistent with the test time. Note that the console may use UTC+0.
• Whether the platform is correctly displayed as Web, iOS, or Android.

Click on the event row or Details to open the event details drawer and review the complete information.

View risk signals

An event may hit zero or more risk signals. Missing the risk signal does not mean that the access failed, it only means that this request did not detect the relevant risks defined by the current system.

If the signal is hit:

1. View the Signal Code and localized description.
2. Confirm whether the signal supports the current platform.
3. Combine the event environment and business behavior judgment, and do not directly and permanently ban users based on a single signal.
4. You can go to the Risk Signals page to view the triggering trend of the signal within the selected time period.

If you wish to test a specific signal, please use the legal testing methods or testing environments provided by the product. Do not create test results by bypassing security restrictions, tampering with production clients, or attacking production systems.

Verify device aggregation

After completing the first event, you can enter the Device page and query the corresponding device through the Device ID.

The first time there is only one event, the device details will usually show:

• Device ID.
• The first-seen time within the storage period.
• Recent device properties.
• The first Request ID in the event log.

After initiating identification again from the same test device, you can check whether the new events are aggregated to the same device. Because the stable range of Device ID is affected by product identification rules, applications, and Region boundaries, do not use cross-application or cross-Region testing to determine whether the same device aggregation is correct.