Product Overview
Core capabilities, use cases, and integration guidance for Device Fingerprint
Device Fingerprint helps businesses identify devices, assess runtime environment risk, and feed the result into key flows such as registration, login, transactions, marketing, and content interaction.
Core Capabilities
Stable Device Identification
Generates stable device IDs from multi-dimensional weak signals to identify reused devices, linked accounts, and abnormal traffic sources.
Client-Side Risk Detection
Detects risky runtime states such as virtualization, automation, debugging, root / jailbreak, hook injection, and environment spoofing.
Server-Side Result Query
The client collects and submits signals, while the server completes the final query and obtains fp, risk_code, risk_label, and related results.
Multi-Region Deployment
Supports Global, Europe, and North America regions with localized storage options to balance performance and compliance.
Risk Coverage
The service can help identify common risky environments such as:
- Virtual devices and emulators
- Automated environments
- Debugging environments
- System tampering
- Root / jailbreak
- Hook and code injection
- Environment spoofing
Typical Use Cases
| Scenario | Main Goal | Common Actions |
|---|---|---|
| Account Security | Detect bulk registration, credential abuse, and account takeover risk | Allow, step-up verification, restrict actions |
| Transaction Risk Control | Identify abnormal ordering, payment, and refund devices | Block, review, manual investigation |
| Marketing Protection | Detect device reuse, bulk participation, and automation | Rate limit, downgrade, eligibility checks |
| Content & Community Safety | Detect spam, fake engagement, and bulk interactions | Review, throttle, ban |
| Game Security | Detect cheating devices and studio-like behavior | Extra verification, matching restrictions, penalties |
Best Practices
Isolate Apps and Secrets
It is recommended to split appId by business scenario, platform, and region, and manage private_key separately on the server for better strategy tuning, data isolation, and troubleshooting.
Keep Final Decisioning on the Server
The client should only collect and submit results. Do not store private_key on the client or make final risk decisions there.
Pre-Launch Checklist
- Client integration is complete for Web, Android, or iOS
- The server-side query flow is connected
- Both online and fallback token paths are verified
risk_codeandrisk_labelhave been wired into business policies
Start with the shortest integration path first, then gradually connect device risk results to allow, verify, rate limit, review, or reject actions.