Core objects and data relationships
Product Introduction And Core Concepts: Core objects and data relationships
Geelab uses a hierarchical structure to manage member permissions, data areas, business applications and technology access. Understanding the relationships between these objects helps to correctly plan applications, keys, and data query scopes.
object relationship diagram
Illustration: Geelab core object relationships
Core object description
organization
Organizations are the top-level container for members, subscriptions, product permissions, and business assets. The master account is responsible for organizational management, and invited members access the console according to their assigned product permissions.
Region
Region is the boundary for data storage, processing, and key isolation. Applications must select a Region when created, and the choice cannot be changed later. It determines:
- Where application data is stored and processed.
- The scope of the Region server key.
- The applications that a Webhook can be bound to.
- The query boundary for event and visitor data.
Application
An application represents an independent business project, such as a main mall website, a payment product, or mobile banking. Applications are business containers for data, quotas, and endpoints.
endpoints
- Platform type.
- Public API Key.
- Source or application signature verification configuration.
- Request rate-limit configuration.
- Enable or disable status.
For example, a "mall" application can create three endpoints: "Web settlement page", "iOS client" and "Android client".
event
An event is a record formed in Geelab for one device identification request. Each event is uniquely identified by request_id and associated with its organization, Region, application, and endpoint.
visitor
A visitor is a device view aggregated by device_id within a specific application's data scope. Visitor details summarize the following during the current data-retention period:
- Time of first appearance.
- Last access time.
- Number of events.
- Risk signals that have been hit.
- Recent and historical device environments.
- Event log.
Visitors represent the aggregation results of device dimensions and do not represent real natural person profiles.
risk signal
A risk signal has a Signal Code, description, risk classification, risk level, and supporting platform. The signal names and descriptions in the console should be based on the Unified Risk Signal Dictionary.
Permissions and data isolation scope
| Object/Ability | main scope | Main permission requirements | Quarantine rules |
|---|---|---|---|
| Organization settings | organization | Master account; members are granted product permissions by organization | Members, assets, and subscriptions of different organizations are isolated from each other |
| Member management | organization | organization owner | Member permissions only take effect for the current organization |
| Region | Data area within organization | Have Device Fingerprint product access | Applications, keys and data in different Regions are isolated from each other |
| Application | Organization × Region | Device Fingerprint product access (reading and writing) | Applications can only belong to one Region |
| endpoints | Application | Device Fingerprint product access (reading and writing) | Public API Key only corresponds to the current endpoints |
| event | App × Region | Device Fingerprint product access (reading and writing) | Query results must not be returned mixed across applications or regions |
| visitor | App × Region | Device Fingerprint product access (reading and writing) | The visitor aggregation scope should be consistent with the current application and Region |
| Risk Signal Statistics | Applications or all applications under the current Region | Device Fingerprint product access (reading and writing) | "All Applications" only summarizes the current Region and does not return data across Regions |
| Server key | Region | It is recommended to limit access to key management | Application sharing under the same Region cannot be used in other Regions |
| Webhook | Region × application collection | It is recommended to limit configuration management rights to | Only applications under the selected Region can be bound |
The first phase of member permissions is granted by product. Device fingerprint products only have two statuses: "with permission (read and write)" and "without permission". High-risk operations such as server-side key rotation, member management, deleting apps, and modifying Webhooks should still be subject to organization administrator and page confirmation requirements.