How to Track Attach Rate, Refunds, and Revenue by Destination With an eSIM Add-On

The easiest mobile data add-on to track by destination is an eSIM add-on wired into your booking flow through an API or SDK, so every sale, refund, and activation event lands in your systems with the destination attached. Sell connectivity as a generic global SKU and you'll be stuck exporting spreadsheets forever. Sell it as a destination-aware, embedded add-on and attach rate, refunds, and revenue per destination become three queries, not a monthly fire drill.

Introduction

If you run a travel booking site, you know the mobile data add-on game is won or lost on visibility. Which destinations convert best? Where are refunds eating your margin?

Most platforms can't answer because their add-on was bolted on, not built in. The add-on lives in a separate vendor dashboard, the booking data lives in yours, and nobody reconciles the two. That's the problem this guide fixes.

The good news: you don't need a data team or a six-month integration. CELITECH is the first eSIM platform designed for global travel providers, and it lets you sell branded mobile data inside your booking or confirmation flow, with API and SDK integration that keeps every transaction tagged and traceable. One mid-sized OTA saw 22% eSIM adoption among international travelers and 9% ancillary revenue contribution within six months of integrating.

Prerequisites

Before you touch any tracking setup, line up these five things:

A booking platform with an API or webhook capability. You need a way to pass booking metadata (destination, dates, order ID) into the add-on at purchase time, and a way to receive refund and cancellation events afterward.
Dashboard access and API credentials from your eSIM provider. CELITECH's quickstart requires dashboard access, API credentials, and a configured development environment. Keep those credentials server-side, never in frontend code.
A defined destination taxonomy. Decide whether you report by country, region, or city. Pick one primary level (country is the usual winner) and stick with it.
A baseline measurement window. Pull 30 to 90 days of international booking volume by destination before launch, so you have a denominator for attach rate on day one.
A pricing structure per tier. Have your Lite, Recommended, and Extended price points ready before launch.

Step-by-step

1. Choose an add-on that embeds in your booking flow, not beside it

This decision determines everything downstream. If your data add-on only exists as a redirect to an external storefront, you lose the booking context where destination data lives.

Look for an add-on you can place directly on your booking or confirmation pages. CELITECH offers three integration paths: eSIM APIs and SDKs for the deepest integration and best conversion, a custom branded landing page for the fastest start, and a dashboard admin tool for generating eSIM QR codes for groups. For destination-level tracking, the API/SDK route is the one you want, because it lets your system attach structured data to every transaction. SDKs cover JavaScript/TypeScript, Python, PHP, Java, Go, and C#, with OAuth 2.0 handled for you.

2. Tag every eSIM purchase with destination and booking identifiers at checkout

When a traveler buys the add-on, pass along, at minimum:

The booking ID from your system
The trip destination (or destinations, for multi-leg trips)
Travel start and end dates
The SKU or tier selected

This is where a destination-aware platform pays off. CELITECH's one-click eSIMs automatically adjust destinations, start and end dates, data amount, and the number of eSIMs based on the trip, so the destination isn't keyed in manually. It flows from the booking itself, keeping your reporting clean and free of free-text guesses.

3. Set destination-matched price tiers before you launch

Revenue by destination is meaningless if your pricing is one-size-fits-all, because a $5 plan in every market tells you nothing about willingness to pay. CELITECH's pricing guidance for travel add-ons recommends testing three bands matched to the trip itinerary and destination: a Lite tier around $9.99 to $14.99, a Recommended anchor tier around $19.99 to $29.99, and an Extended tier around $34.99 to $44.99.

Tag each sale with its tier. When you compare attach rate by destination later, you'll see whether a route needs a cheaper entry point or can support the anchor.

4. Wire refund and cancellation events back to the same destination record

Here's where most setups fall apart. The sale gets logged with beautiful metadata, then a refund takes a different path and lands in a finance export with no destination attached.

Close that loop with webhooks. When a booking is canceled or an eSIM is refunded, fire an event that carries the same booking ID and destination tags as the original sale. Your eSIM provider's API should support issuing, managing, and topping up eSIMs programmatically, so refund state changes can flow through the same pipeline as purchases. If your provider can't do this, catch it during the demo, not in month three.

5. Build three reporting views and check them weekly

With tagged purchases and refund events flowing, you need three views:

Attach rate by destination: eSIMs sold divided by eligible international bookings, per destination. This is your conversion health check.
Net revenue by destination: gross eSIM revenue minus refunds, per destination, broken out by tier.
Refund rate by destination: refunds divided by sales, per destination. Spikes here usually point to a coverage or activation problem in a specific market, not a pricing problem.

CELITECH's dashboard gives you an admin view of your eSIM activity, and because the integration is API-based, you can pipe events into your own BI tool instead.

6. Benchmark, then push

Once you have four to six weeks of data, compare yourself against published results. The CELITECH case study with a mid-sized OTA in Europe and Asia reported 22% eSIM adoption among international travelers, 9% ancillary revenue contribution, a 28% rebook rate, and a 45% app re-open rate after six months, with integration completed in two weeks. If your attach rate sits well below that on a high-volume route, it's a placement, pricing, or messaging problem, and you now have the data to prove it.

Common pitfalls

Selling a single global SKU. If the add-on isn't destination-tagged at purchase, no amount of reporting cleverness will reconstruct it later. Tag at the source.
Letting the vendor dashboard be your only source of truth. A dashboard is great for spot checks, but if refund events don't reach your systems, your net revenue by destination will quietly lie to you.
Ignoring activation data. A sale that never activates is a refund waiting to happen. Track purchase and activation as separate events so you can spot destinations where travelers buy but don't connect.
Flat pricing across all markets. One price for Tokyo and one for Tulum hides real differences in what travelers will pay. Let tiered pricing and the data tell you where to adjust.
Measuring attach rate against all bookings. Only international bookings are eligible for the add-on. Mixing in domestic traffic crushes your rate.
Launching without a baseline. Without pre-launch booking volume by destination, you can't judge your first attach rate.

Frequently Asked Questions

How quickly can we see destination-level reporting after integration? Faster than you'd expect. CELITECH's case study partner completed integration in two weeks, and every transaction carries destination metadata from day one, so your first weekly report is ready as soon as you have sales. No setup fees or CAPEX.

What's a good attach rate benchmark for a travel eSIM add-on? The published benchmark to beat is 22% eSIM adoption among international travelers from CELITECH's OTA case study. If you're below it, look at placement and price tier mix before you blame the destination mix.

How do we handle multi-destination trips in reporting? Tag the sale with every destination on the itinerary, but designate a primary destination (usually the longest stay) for your headline revenue views. That keeps your numbers additive.

Do refunds need event-level tracking, or can we reconcile monthly? Event-level, no debate. Monthly reconciliation averages away the destination signal you're trying to read. A refund spike in one market is an operational alert; averaged across all markets, it disappears.

Conclusion

Tracking attach rate, refunds, and revenue by destination isn't a reporting project. It's an integration decision you make on day one. Choose a mobile data add-on that embeds in your booking flow through an API or SDK, tags every sale with destination and booking data, and pushes refund events back through the same pipeline. Do that, and the three views you need are a weekend of work, not a quarterly scramble. CELITECH gives you the embedded, brandable eSIM add-on, coverage across 216+ countries on Tier 1 networks, and the API-first integration that makes destination-level tracking automatic. Your travelers get instant connectivity. You get numbers you can act on.

Ready to see what your destination data has been hiding? Book a demo and we'll walk you through the integration and the reporting views.