Verify the first identification event

After the SDK access is completed, a real identification should be initiated in the test environment and the event must be confirmed on the console.

Initiate a test request

1. Launch a test website or app.
2. Open the test page or business portal that has integrated the SDK.
3. Perform an identification call.
4. Record the returned request_id.
5. If the SDK returns device_id, recorded at the same time for comparison.

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.

Illustration: Query events using Request ID

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 endpoints.
• 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.

Illustration: Details of the first identification event

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.

Illustration: Risk signals of event hits

It is recommended to prepare two small pictures for side-by-side display: "Missed risk signals" and "Hit multiple risk signals". A description entry should be provided next to the signal tag.

Verify visitor aggregation

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

The first time there is only one event, the visitor 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 visitor. 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 visitor aggregation is correct.

Image: Event log in visitor details