An analytics event can say, “the client reports a purchase.” It cannot, by itself, say, “the store accepted payment and this account owns the item.” Keeping those statements separate is the difference between useful telemetry and accidentally treating a client message as a financial record.
I reviewed the current source snapshot of Advanced Game Analytics, a private C# portfolio prototype for game-economy events. Its EconomyEvent class is a useful place to examine that boundary because the same object carries product, revenue, currency, and optional receipt data. This is a source review of the checked-in snapshot, not a claim that a complete Unity SDK is running in production.
ADVANCED GAME ANALYTICS / TRUST BOUNDARY
Describe a purchase. Verify it elsewhere.- 01 / CLIENT INPUTEconomyEvent.IAPPurchase(...)
product_id · revenue · currency_codeThe client constructs a report about a purchase.
- 02 / LOCAL CHECKSValidate event shaperevenue > 0 → error otherwisemissing product ID → warning
These checks improve input quality; they do not contact a store.
- 03 / RECEIPT FIELDWithReceipt(value)
_receiptData = valueThe object retains the supplied string and marks itself as containing PII.
No verifier, event transport, or entitlement ledger is included in the reviewed snapshot.
Model what the client observed
The IAPPurchase factory creates an EconomyEvent, assigns a product ID, and adds a revenue amount with a currency code. The constructor creates a local identifier such as txn_<guid>. That makes the event easier to correlate inside a client flow, but a random client-generated ID is not a store transaction ID and does not prove that a transaction happened.
The class also has a small set of local validation rules. For an in-app purchase it reports an error when revenue is not positive and a warning when the product ID is missing. Those checks can catch incomplete or obviously invalid event data before a consumer handles it. They cannot make the client authoritative: a modified client can still fabricate a plausible product ID and amount.
That distinction shaped the way I read the model. I ask two separate questions: is this event internally well-formed, and has a trusted service verified the purchase? The first can be answered by local validation. The second requires a server-side flow that checks the platform’s purchase evidence and then applies the entitlement or balance change under a clear duplicate policy.
A receipt field changes the privacy story
The source has a WithReceipt method. In the reviewed file, that method assigns the supplied string to a private _receiptData field and adds a has_receipt flag to the event parameters. ContainsPII becomes true when _receiptData is non-empty. The parameter bag does not receive the receipt string, but the event object still retains it in memory.
That behavior is narrower than uploading or logging a receipt, but it is not the same as “receipt presence only.” A caller that passes a real receipt must treat the object as sensitive for as long as it exists and must ensure later serializers, diagnostics, crash reports, and logs cannot expose its private state. The safer analytics contract is usually to keep raw store evidence out of the telemetry event altogether. Send it only through a dedicated verification path with deliberate access and retention rules; let analytics receive a verified outcome or a non-sensitive reference.
Put authority on the server side
The reviewed repository does not include event transport, persistence, server-side receipt verification, or an entitlement ledger. So the implementation cannot demonstrate a full purchase lifecycle. A production design would verify the receipt with the appropriate store service, bind the result to the intended account and product, record the store transaction under a uniqueness rule, and grant the entitlement only after that authoritative check succeeds.
Retries then become a normal part of the design. If the verification request or response is repeated, the transaction identity must let the trusted service return the same outcome without granting the item twice. The event’s locally generated ID may help trace a client attempt, but it is not enough to deduplicate against a store’s transaction record.
Treat the repository snapshot as evidence too
There is an important limit to what I can claim about this prototype. At the reviewed commit, the repository contains EconomyEvent.cs but not the referenced AnalyticsEventBase or IMonetaryEvent definitions, a project file, or the test project described in the README. The README example also calls WithTransactionId, which is not present in the checked-in C# file. The workflow only lists the repository structure; it does not build the library or run tests.
That means I can explain the visible factory, fields, and validation branches, but I cannot claim the snapshot compiles, integrates with Unity, verifies receipts, or safely serializes every event. Before presenting it as a reusable library, I would restore the missing project contract, remove raw receipt retention from the analytics model, and add tests for invalid revenue, missing product IDs, receipt handling, and duplicate transaction behavior in the trusted consumer.
What this event model can safely claim
At this snapshot, the model can describe a client-reported product and amount, flag a locally retained receipt as sensitive, and report a validation error for non-positive revenue. It cannot verify a store transaction or grant an entitlement: the repository has no receipt-verification service or ledger, and its checked-in project contract is incomplete. The next useful change is to restore a buildable, tested library contract and keep raw receipt data out of analytics events; purchase ownership should be established by a separate trusted verification path.
Advanced Game Analytics is a private prototype. This note describes the reviewed source at a high level and does not publish its code or assets.