TopCashback Integration Data Flow

A partner-specific data flow for the TopCashback (TCB) integration, written to answer the kind of question a vendor security review asks: what data crosses each boundary, who processes it, where does it come to rest, and for how long.

For the generic, publisher-agnostic view see Offerwall Integration Architecture.

Integration shape. TopCashback is a link-out (Direct Link), non-SDK integration. No AdGem code runs inside a TopCashback client. Publisher 32172, app 33062.

Entry is fronted by Partnerize, TopCashback's affiliate tracking platform. This means the flow has an inbound leg from a third party and an outbound conversion leg back to that third party, neither of which appears in the generic diagram.

Partnerize is also the only return channel. Unlike a standard publisher integration, AdGem does not post a conversion webhook directly to the publisher's backend here. Conversions go to Partnerize, which forwards to TopCashback, and TopCashback issues the member reward.

Sequence, with data annotated

Third parties in the TopCashback path

Party	Role	Personal data it sees	Direction
Partnerize (prf.hn)	TCB's affiliate tracking platform	clickref, custref (TCB member ID), country, currency, conversion value	Inbound redirect + outbound from AdGem
Cloudflare	TLS termination / WAF in front of api.adgem.com and dashboard.adgem.com	All request data in transit: IP, user agent, cookies, URL parameters including playerid	Processes on AdGem's behalf
Tune	Click tracking and campaign management	Click identifiers, device identifiers, IP, geo	Processes on AdGem's behalf
Datadog	Observability	Application logs containing IPs, Play IDs, device identifiers	Processes on AdGem's behalf
AWS	Cloud infrastructure and hosting	All of the above at rest and in transit	Processes on AdGem's behalf

Geolocation is resolved against a locally hosted MaxMind GeoIP database. No request data is sent to MaxMind, so it is a data supplier rather than a party in this flow and does not belong on the table above.

Edge topology

The two AdGem-facing origins sit behind different edges, which matters when reasoning about who terminates TLS:

• adunits.adgem.com (offerwall UI) is served by AWS Amplify through CloudFront. Confirmed by response headers: via: CloudFront, x-cache: Hit from cloudfront.
• api.adgem.com and dashboard.adgem.com are fronted by Cloudflare, which terminates TLS for those origins.

Subprocessor classification. The useful line is direction of flow. Where personal data leaves AdGem to a third party that processes it on our behalf, that party is a subprocessor. Where a third party supplies reference data we consume locally, it is a supplier and no personal data leaves.

On that test Cloudflare, Tune, Datadog and AWS are subprocessors. MaxMind is a supplier, since we resolve geolocation against a locally hosted GeoIP database and no request data leaves for it.

Partnerize is the ambiguous one. AdGem posts conversion data to it, but it is TopCashback's own platform, engaged at TopCashback's instruction. That reads more like an onward disclosure to the partner's processor than an AdGem subprocessor. Either way it belongs on this diagram. Classification is a legal call, not an engineering one.

Data inventory

Field lists are drawn from ADR 0044, Appendix A.

Category	Fields	Captured at	Comes to rest in
Publisher-supplied identifier	player_id (TopCashback member ID)	Entry URL	Postgres, Redshift, outbound to Partnerize as custref
Affiliate click reference	c1 / clickref	Entry URL	ClickEvent (Postgres), echoed to Partnerize
AdGem identifier	adgem_uid	Click	Postgres, Redshift
Network / device identifiers	ip, idfa, gaid, oaid, android_id, useragent, platform, os_version, connection_type, carrier_name, isp	Click and post-install events	Postgres, Kinesis → Firehose → S3 → Redshift
Geographic	country, city, postal_code, lat/lon	Click	Postgres, Redshift
Campaign / transaction	app_id, campaign_id, publisher_id, transaction_id, payout, offer_name, goal_name	Click and conversion	Postgres, Redshift, outbound to Partnerize

AdGem does not receive TopCashback account credentials, email addresses, or payment details. The member ID is a pseudonymous identifier issued by TopCashback.

Jurisdiction

All AdGem processing and storage is United States based (AWS US regions). TopCashback is UK based, so member data moves US-ward on entry. Transfer mechanism is governed by the DPA and is a legal question rather than an architectural one.

Retention

Adopted January 2026, enforcement targeted for Q1 2027. ADR 0044 establishes a uniform 12-month retention standard for personal and indirect PII, after which data is deleted, anonymized or aggregated. It was accepted on 2026-01-27, but the automated deletion and anonymization workflows described in it have not been built. The ADR says so in its own Context section: data currently persists indefinitely in Redshift, S3 Firehose archives and production Postgres.

Automated enforcement is targeted for Q1 2027. For the TopCashback integration specifically that ordering works out: the integration enters service in Q3 2026, so no TopCashback data reaches the 12-month threshold until roughly Q3 2027, comfortably after enforcement lands.

Anything stated externally should describe 12 months as a standard adopted earlier this year with implementation in progress, not as a control operating today.

Store	Policy target (ADR 0044)	Implemented today
Redshift / S3 Firehose	12 months, then anonymize or delete	No, retained indefinitely
Production Postgres	Active campaign + 12 months	No, retained indefinitely
RDS automated backups	7 days	Yes, existing AWS configuration
Redshift automated snapshots	1 day	Yes, existing AWS configuration
Redshift manual snapshots	Max 365 days	No, currently indefinite
Aggregated / anonymized data	Indefinite, no PII	n/a

Third-party constraint worth noting: Tune retains transactional detail for 123 days, then summary data only.

Open items

1. commission macro. The configured outbound postback currently sends commission:{payout}. Partnerize guidance is that commission should be the reward to the end user, which suggests commission:{amount}. Raised by Kevin Brogan, unresolved. Integration detail rather than a data-flow question, so it does not belong in partner-facing collateral.
2. Retention implementation owner. Q1 2027 is the target date; the owning team is not yet named.

Related

A partner-facing version of this flow lives in the repository at partner-collateral/topcashback-data-flow.pdf, with its HTML source and regeneration instructions alongside it. That version drops code names and ADR references, omits the open items above, and states geolocation and edge topology in terms an external reviewer can act on.

The two documents describe the same system and must stay consistent. Neither is generated from the other, so a correction here needs applying there by hand.