Server-Side Tracking for Crypto Apps: Setup Guide (2026)

Server-side tracking for crypto apps means recording analytics and conversion events from infrastructure you control (your backend, an indexer reading your contracts, or a first-party proxy) instead of relying only on a script in the user's browser. For onchain apps, it is the only way to measure the conversions that matter, because most of them happen on a blockchain, not on a web page.

Client-side tracking still has a job: it captures the landing page, the campaign parameters, and the wallet connect. But a browser script cannot see a swap executed by a bundler, a deposit made from a mobile app, or a trade placed by an API bot, and it is blocked outright for a large share of visitors. GWI data for Q2 2025 shows that 29.5% of internet users worldwide use an ad blocker, and Brave, a privacy browser with a built-in crypto wallet, passed 100 million monthly active users in September 2025.

This guide explains how server-side tracking works, why crypto apps need a hybrid setup, how to treat onchain transactions as server-side conversions, how to send them to ad platforms without duplicates, and how to stay within privacy rules.

What is server-side tracking?

Server-side tracking is a method of collecting analytics events on a server you control and forwarding them to analytics or ad platforms from there. Client-side tracking sends events directly from a script in the browser or app. Server-side tracking is harder to block, more reliable for revenue events, and gives you control over what data leaves your systems.

Google describes its server-side tagging container as one that "doesn't run in the user's browser or on their phone. Instead, it runs on a server that you control" (Google Tag Platform). Segment's guidance is that client libraries are best for context such as UTM parameters, device, and page views, while server libraries are best for "mission-critical data like revenues," and that most teams should use a mix of both (Segment docs).

See the server-side tracking glossary entry for a short definition.

Why client-side tracking breaks for crypto apps

Every web product loses some data to blockers and browser privacy rules. Crypto apps lose more, because their conversions often happen outside the browser session entirely.

1. Ad blockers and privacy browsers drop events

Ad blockers block requests to known analytics domains. In GWI's Q2 2025 data, ad blocker use reached 32.5% in the US and 34.5% among men aged 25 to 34, a demographic that overlaps heavily with crypto users. Brave blocks trackers by default and ships its own wallet. There is no rigorous survey of ad blocker use among crypto users specifically, so measure your own gap: compare client-side wallet connects with onchain transactions from the same contracts.

2. Safari limits client-side cookies

According to WebKit's tracking prevention documentation, Safari deletes script-writable storage after 7 days without user interaction, and caps cookies set by JavaScript to 24 hours when a visitor lands from a URL with click identifiers. A user who clicks an ad today and deposits next week can lose their campaign attribution if it only lives in a browser cookie.

3. The conversion is not on the page

In a typical SaaS funnel, the conversion is a form submit or a checkout that the browser sees. In crypto, the conversion is a transaction that is confirmed onchain after the user signs, and often it is submitted by someone else:

• Smart accounts: under ERC-4337, users sign UserOperations, bundlers submit them, and paymasters can sponsor gas.

• Embedded wallets and relayers: the app's backend or a relayer often submits gasless transactions.

• Intents and solvers: a solver fills the order, sometimes minutes later, on a different chain.

• Bots, API traders, and mobile apps: there is no web page at all.

• Direct contract calls: power users interact with your contracts from block explorers or aggregators.

The browser may see "Swap button clicked." Only the chain can tell you the swap succeeded, for how much, and on which network.

4. Paid channels are restricted anyway

Google's cryptocurrency ads policy does not allow ads for DeFi trading protocols in most cases, and Meta requires written permission and a regulatory license for exchanges, trading, and lending products. For many DeFi teams, server-side tracking is less about feeding an ad algorithm and more about complete analytics and attribution across KOLs, referrals, community, and the ad networks they can use.

Which events should be tracked client-side, server-side, or onchain?

Track each event at the layer that observes it most reliably. Context is a browser fact. Business outcomes are a backend or chain fact.

For a full event list by app type, see the DeFi tracking plan.

A reference architecture for crypto server-side tracking

A production setup for an onchain app has four sources and one join key.

1. Client SDK through a reverse proxy. Route the web SDK's requests through your own domain (for example with Next.js rewrites or a Cloudflare worker). This captures landing context, wallet connects, and signatures with fewer blocked requests.

2. Server SDK in your backend. Send signups, account states, relayed transactions, and revenue events from your API or job workers.

3. Contract event ingestion. Decode events from your contracts (Swap, Deposit, Transfer) with an indexer, so every onchain conversion is recorded, whatever the client.

4. Optional ad platform adapter. A separate service maps a small set of internal conversions to each ad platform's conversion API, with consent checks and minimal fields.

5. Join key: the wallet address. The client SDK links the session and campaign to the wallet at connect. Server and onchain events carry the same address, so they land on the same user profile and inherit its attribution.

This keeps detailed wallet, session, and transaction joins inside an access-controlled analytics system, while only a minimal payload ever goes to external platforms. The DeFi analytics stack guide explains where each layer fits.

How to track onchain transactions as server-side conversions

To track an onchain transaction as a conversion, define the exact contract event that counts, decide the confirmation threshold, and give each conversion a stable ID built from the chain ID, transaction hash, and log index. Then record it from your indexer or backend, never from the button click.

1. Define the success event. For a lending app, a Deposit event from your pool contract with an amount above a minimum, not "Deposit button clicked."

2. Separate statuses. Record submitted, included, confirmed, and failed as distinct states. Report conversions only on confirmed.

3. Set a confirmation threshold per chain. Decide how many blocks or which finality level counts as confirmed, and handle reorgs by reversing events from orphaned blocks.

4. Build an idempotent event ID. Use chainId:txHash:logIndex. Retries, replays, and backfills then cannot create duplicates.

5. Attach value. Store the token amount, the USD value at execution time, and the fee or revenue your protocol earned.

6. Link to the user. Use the address that the event credits (the depositor or recipient), not the bundler or relayer that paid gas.

The last step is the one most teams get wrong. With account abstraction, the transaction sender is often infrastructure. Use the account address emitted in the event instead. See onchain attribution for how this links back to campaigns.

How to send server-side conversions to ad platforms without duplicates

If you send the same conversion from a browser pixel and from your server, give both copies the same event ID so the platform keeps only one. Each platform has its own rules and time windows.

Three crypto-specific rules apply:

• Store click IDs at landing. Capture gclid, fbclid, twclid, and rdt_cid on the first visit and attach them to the wallet at connect. You need them later, when the transaction confirms.

• Send late conversions server-only. A deposit that confirms days after the click falls outside Meta's 48-hour deduplication window. Do not fire a browser twin for it; send one server event.

• Do not send wallet addresses by default. They are not a standard matching field, and they expose financial history. Send the event name, time, event ID, permitted click IDs, and value.

Does server-side tracking bypass consent?

No. Server-side tracking changes where events are sent from, not whether you are allowed to collect them. Consent, notice, and data minimization rules still apply, and ad platforms still require you to honor user choices.

Wallet data needs extra care. The European Data Protection Board's Guidelines 02/2025 on blockchain (version 2.0, adopted July 2026) state that wallet addresses and public keys are personal data when a person can be identified by means reasonably likely to be used. Linking a wallet to a cookie, an IP address, or an email is exactly that kind of means. France's CNIL reached a similar view in its 2018 blockchain guidance.

• Apply the same consent state to server events as to the client events they relate to.

• Never send private keys, seed phrases, signed messages, or raw transaction payloads to any analytics or ad platform.

• Document what each destination receives, how long it is kept, and how deletion requests are handled.

See cookieless attribution for privacy-first measurement methods.

How to set up server-side tracking with Formo

Formo supports each layer of the hybrid architecture: a web and mobile SDK with reverse proxy support, a Node.js server SDK and HTTP Events API, and contract event ingestion. All events land on the same wallet profile, with first-touch and last-touch attribution.

Step 1: Route the web SDK through your domain

Set up a reverse proxy (Next.js rewrites, middleware, or Cloudflare) and pass its URL as apiHost in the SDK options. See the reverse proxy guide.

Step 2: Send backend events with the server SDK

Install @formo/analytics-node and track conversions from your backend with the wallet address the user connected:

import { FormoAnalytics } from "@formo/analytics-node";

const analytics = new FormoAnalytics(process.env.FORMO_WRITE_KEY);

await analytics.track({
  address: "0x9798d87366bdfc5d70b300abdffc4f9e95369b3d",
  event: "Deposit Confirmed",
  properties: {
    chain_id: 8453,
    tx_hash: "0xabc...",
    volume: 2500,
    revenue: 2.5,
  },
});

// In serverless functions, flush before the handler returns
await analytics.flush();

The server SDK is stateless, so pass the wallet address on every call. In serverless environments such as AWS Lambda or Vercel, call flush() before the function returns. Details are in the server SDK docs, and any other language can post to the Events API.

Step 3: Ingest contract events

Add your contracts in project settings, select the events to track, and deploy the pipeline. Formo decodes events such as Swap or Deposit in real time and adds them to the activity feed, wallet profiles, and funnels. The contract events guide walks through it.

Step 4: Validate

• Compare client wallet connects with confirmed contract events for the same period to estimate your blocked-event gap.

• Test browser-only, server-only, and dual delivery for each conversion, and confirm that duplicates collapse to one.

• Replay a block range and confirm that idempotent event IDs prevent double counts.

• Reconcile tracked volume and revenue with your contracts or treasury every week.

Frequently asked questions

What is server-side tracking for crypto apps?

Server-side tracking for crypto apps records events from your backend, an indexer reading your smart contracts, or a first-party proxy, instead of only from a browser script. It captures onchain conversions that the browser never sees, such as bundled, relayed, mobile, or bot transactions, and it is not affected by ad blockers.

Is server-side tracking better than client-side tracking?

Neither is complete alone. Client-side tracking captures context such as UTMs, referrers, and wallet connects. Server-side tracking captures confirmed outcomes such as deposits and revenue. Crypto apps should use a hybrid setup joined by the wallet address.

Does server-side tracking bypass ad blockers?

Events sent from your servers or from contract indexing are not affected by browser ad blockers. Client events can still be blocked, so route the client SDK through a reverse proxy on your own domain. Server-side tracking does not remove your consent obligations.

How do I track onchain transactions as conversions?

Define the contract event that counts, wait for your confirmation threshold, and record the conversion from an indexer or backend with an ID built from chain ID, transaction hash, and log index. Credit the account in the event, not the bundler or relayer that paid gas.

How do I prevent duplicate conversions?

Use one stable event ID for every copy of a conversion and make retries idempotent. For Meta, match the Pixel eventID and the Conversions API event_id within 48 hours. For Google Ads, reuse the same transaction ID. Send late onchain conversions from the server only.

Should I send wallet addresses to ad platforms?

Generally no. A wallet address is not a standard matching field, it exposes financial history, and EU regulators treat it as personal data when it can be linked to a person. Keep wallet joins in your analytics system and send only the fields each platform needs.

Can DeFi apps use the Google Ads or Meta Conversions API?

Only if they are allowed to advertise. Google does not allow ads for DeFi trading protocols in most cases, and Meta requires a regulatory license and written permission for exchange, trading, and lending products. Many DeFi teams use server-side tracking mainly for analytics and attribution across other channels.