Selecting a Pointer Record
Pointer records connect licenses to data stored in your system.
TIKI does not store user data; it's never even sent to a TIKI server —hence the SDK. Licenses are created where user data originates: the application layer.
Doing so requires a pointer record, aka a foreign key —just as if you were to collect and manage license records in your own database (please spare me the panic and don't tell me you'd stuff it all in your user table).
What's a Good Identifier?
Like foreign keys, pointer records are powerful when well-planned.
-
Use strong identifiers that will not change —licenses are immutable.
For example, use a userId, instead of an email address.
-
Where possible, be specific, limiting scope to specific datasets —you will see improvements in searchability and ease of use downstream.
For example, use an advertising ID (MAID) for ad attribution data instead of userId.
-
Use opaque IDs to decouple and protect user privacy —for good measure, hash pointer records before storage.
Note: For highly sensitive applications, use a compute-intensive hash (pbkdf2, bcrypt, scrypt, etc.) or generate a new random identifier for licensing-only purposes.
Example:
userId = "93c3e608-322f-4969-9ffd-b4c2329ab0b"
TikiSdk.config()
.offer
.ptr("93c3e608-322f-4969-9ffd-b4c2329ab0b")
try? TikiSdk.config()
.offer
.ptr("93c3e608-322f-4969-9ffd-b4c2329ab0b")
TikiSdk
.offer
.ptr("93c3e608-322f-4969-9ffd-b4c2329ab0b")
await TikiSdk.config()
.offer
.ptr("93c3e608-322f-4969-9ffd-b4c2329ab0b")
Updated 7 months ago