Changelog
Platform changes that affect the integration or the behavior the client observes.
The tag installed on the client’s site does not need to be replaced on every update. It is served by the platform and updates itself — with the 5-minute cache window, a fix reaches every visitor within minutes. The one exception is a change to the campaign identifier, which does require a new tag.
Latest update#
Tag caching revised#
The tag moved from a long immutable cache to
max-age=300, must-revalidate, with an ETag and
a conditional 304 response.
The reason: with a one-year cache, a published fix stayed pinned in browsers and CDNs for
months — visitors kept getting the old version. Now revalidation happens every 5 minutes
and returns 304 when nothing changed, so bandwidth cost is close to zero and
the fix lands fast.
Server-side write guard#
The recording routes now verify server-side whether the campaign is configured for the platform’s own measurement — on top of the check the tag was already doing in the browser. Without it, automated calls to the endpoint with a valid campaign identifier (link checkers, browser prefetch, uptime monitors, an old cached pixel) were being recorded, inflating the dashboard with events that were not real traffic.
Earlier updates#
The platform’s own measurement#
Visits and conversions recorded in the platform’s own database, with no redirect on the click. This became the source for the results dashboard, with attribution by traffic source.
Authenticated server-to-server postback#
A new route for conversions reported by the advertiser’s backend, authenticated by a per-campaign token with constant-time comparison. It allows recording conversions without JavaScript and without cookies. See Postback S2S.
Results dashboard#
A screen with filters by period, campaign and traffic source, aggregate tables, latest conversions and CSV export. See the results dashboard.
Independent forwarding per destination#
Forwarding conversions to media platforms is now controlled independently per destination, instead of a single global mode. Existing campaigns were migrated preserving exactly the previous behavior — no campaign changed destination in the update.
Local geolocation#
City detection now uses a local database on the platform’s server instead of depending on an external service. No per-query cost and negligible latency. The external service remains only as a fallback when the local database cannot resolve. See geolocation.
Conditional geolocation#
City detection now runs only on campaigns that actually use a geographic rule. Campaigns with no city restriction stopped calling the service — which also means that in those campaigns the IP address is not used for this purpose.
The retention window for events is 30 days. For longer history, export the dashboard CSV periodically. See Privacy and LGPD (Brazilian General Data Protection Law).