Architecture and security
Technical specification for security review, compliance assessment and vendor questionnaires.
It describes the platform’s architecture and technical controls at the level needed for security and compliance assessment. Implementation details, the identity of vendors and sub-processors, and the specification of the internal routes are provided to the contracting party under the contract and, where applicable, under a confidentiality agreement — including to support a formal audit.
Layers#
Client
Dependency-free ES5 JavaScript, ≈7 KB compressed, loaded with
defer. It runs in the visitor’s browser: reads URL parameters, writes
first-party cookies and sends events.
Application
REST API over HTTPS. It serves the campaign configuration, receives events and authenticates the server-to-server postback by token.
Persistence
Relational database with a unique deduplication key and indexes by campaign, source and date. Automatic removal based on record age.
Data flow#
| Stage | What travels | Direction |
|---|---|---|
| Tag load | Campaign identifier, in the script URL itself | Browser → platform |
| Campaign configuration | Campaign behavior parameters. No visitor data, no secrets | Platform → browser |
| Visit record | Click identifier, source, referrer, campaign parameters, user agent | Browser → platform |
| Conversion record | Click identifier, transaction identifier, value | Browser → platform |
| Server-to-server postback | Click identifier, transaction identifier, value, campaign token | Advertiser’s server → platform |
| Forwarding to media platforms | Click identifier, transaction identifier, value, as required by each contracted platform | Browser or platform → media platform |
Stored data#
On the server, per event#
| Field | Nature | Note |
|---|---|---|
| Campaign | Operational | Identifier and internal name |
| Event type | Operational | Visit or conversion |
| Click identifier | Pseudonymized | Re-identifiable by the media platform that issued it |
| Transaction identifier | Pseudonymized | Re-identifiable by the advertiser in its own system |
| Conversion value | Commercial | Two decimal places |
| Traffic source | Technical | Publisher or channel |
| Referrer | Technical | Up to 500 characters |
| User agent | Technical | Up to 255 characters. May contribute to fingerprint-based identification |
| IP address hash | Pseudonymized | SHA-256 of the IP combined with a site-specific salt. The address itself is not stored |
| Session and device identifiers | Pseudonymized | Only when the campaign uses them |
| Campaign parameters | Pseudonymized | Closed allowlist — see below |
| Date and time | Technical | — |
Name, email, phone number, CPF (Brazilian tax ID), address, payment data, cart contents and IP addresses in readable form. The platform never receives this data from the advertiser and has no way of obtaining it.
In the browser#
First-party cookies holding the identifiers received in the URL, plus two technical control markers that contain no visitor data. Full breakdown in cookies written.
Security controls#
Hashed IP address
The IP is converted to a SHA-256 hash with a site-specific salt before anything is written. The original value is never persisted and cannot be recovered from the hash.
Parameter allowlist
Of the URL parameters, only campaign parameters (utm_ prefix) and a
closed list of ad platform identifiers are kept. Anything else is dropped on input —
personal data accidentally placed in the URL is never stored.
Input size limits
Every field has a maximum size enforced on input, with text sanitization. This blocks injection through long fields and caps how much is written per request.
Database-level deduplication
A unique key over event type, click identifier and transaction identifier. A repeated request is accepted and silently discarded, which makes retries safe and prevents inflating counts through repetition.
Automation filtering
Visits whose agent is identified as a bot, crawler or monitor are not recorded. This does not apply to conversions, so a legitimate customer event with an unusual agent is never discarded.
Per-campaign token, constant-time comparison
The postback is authenticated by a token unique to the campaign, compared in constant time. An invalid token, a missing token and a non-existent campaign produce an identical response, revealing nothing about which campaigns exist.
Public response scope
The routes the browser calls accept no credentials and expose no secrets. The postback token never appears in any API response.
Restricted cookies
First-party cookies only, with SameSite=Lax and Secure over
HTTPS. No third-party cookie is used.
Redirect validation
Redirect URLs configured on a campaign are validated before use, and script-execution schemes are refused — so a misconfiguration can never become an execution vector in the visitor’s browser.
Fail-closed
An error at any stage results in nothing being recorded, never in recording wrong data or breaking the advertiser’s page. See how it works.
Response headers#
| Route | Headers |
|---|---|
| Tag | Cache-Control: public, max-age=300, must-revalidate, ETag, Access-Control-Allow-Origin: * |
| Event recording | Cache-Control: no-store, Access-Control-Allow-Origin: * |
| Postback | Cache-Control: no-store |
Retention and removal#
| Data | Retention | Removal mechanism |
|---|---|---|
| Visit and conversion events | 30 days | Automatic daily job based on record age |
| Browser cookies | Campaign window: default 30 days, maximum 365 | Browser expiry |
| Geolocation cache | 24 h on a hit, 10 min on a failure | Automatic expiry |
| Technical markers in the browser | Session, or until the user clears them | Browser data clearing |
| Campaign configuration | For as long as the campaign exists | Deletion by the operator |
Sub-processors and third parties#
The platform involves third parties in three functions. The identity of each vendor, the location of processing and the corresponding data processing agreements are provided to the contracting party under the contract.
| Function | Data involved | When it happens |
|---|---|---|
| Hosting infrastructure | All stored data | Continuously |
| Contracted media platforms | Click identifier, transaction identifier, value | At conversion, depending on the campaign |
| IP geolocation (external fallback service) | Visitor’s IP address | Only on campaigns with a city rule, and only when the local database cannot resolve. See geolocation |
Geolocation through an external service may constitute an international data transfer. Campaigns that do not use a city rule never trigger that path. Advertisers with restrictions on international transfers should flag this to the Moclick team so campaigns are configured accordingly.
Known limitations#
Stated explicitly because they affect how the data should be read, and because they come up in technical questionnaires:
- Execution in the visitor’s browser. Because this is client-side JavaScript, it is technically possible for third parties to modify, block or prevent its execution. Script blockers stop measurement with no error signal of any kind.
- Dependency on first-party cookies. A user clearing cookies, private browsing or a conversion on a different device all break attribution.
- Impressions and cost in the dashboard are estimates, not measurements — see indicators.
- A 120-second watch window for conversion detection in single-page applications.
- No consent check in the tag. The tag does not query a consent platform on its own. Sites operating with consent management must gate tag loading on the matching category.
- Expected divergence from external platform reports, due to differences in attribution model, window and deduplication criteria.
Continuity and availability#
A platform outage does not affect the advertiser’s site: the tag fails silently and the page keeps working normally. The effect is conversions not recorded during that period, with no error visible to the visitor.
Availability commitments, backup procedures, the recovery plan and incident response are covered by the contract and can be detailed for vendor assessment on request.
Review#
This document is reviewed on every material change to the architecture or to data handling. Changes affecting observable behavior are recorded in the changelog. For a security questionnaire, a vendor assessment or a request for supplementary documentation, contact the Moclick team.