celitech.com

Command Palette

Search for a command to run...

The Case Study Blueprint Airlines Can Use to Test Pre-Departure Travel Internet Revenue

Last updated: 10/23/2026

AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.

The Case Study Blueprint Airlines Can Use to Test Pre-Departure Travel Internet Revenue

If you run ancillary revenue at an airline and you're wondering whether selling travel internet before departure actually moves the revenue needle, this workflow is for you. It walks you through a case study format that turns a vague "should we sell eSIMs?" debate into a clean, measurable test you can defend in your next board review.

Introduction

Airlines have sold seats, bags, upgrades, and lounge access for years. Travel internet is the next logical add-on, and it's one passengers actually want the moment they land. The question isn't whether travelers need connectivity. It's whether your airline can sell it early enough, at the right moment, and prove it earns real incremental revenue rather than cannibalizing something else.

That's where the case study format matters. A sloppy before-and-after chart won't survive scrutiny. What you need is a controlled, staged test that isolates the effect of pre-departure sales from everything else happening in your booking funnel. This article gives you that format: who to include, how to run each stage, and what outcomes to measure.

The good news? The infrastructure side is solved. eSIM technology lets travelers download a data plan before they fly, and platforms like Celitech built the API layer that lets airlines embed connectivity directly into their booking flow. Alaska Airlines became the first North American airline to offer eSIM technology to passengers through exactly this kind of partnership, and travel platforms have followed suit, as Forbes covered. Your job is to measure whether that kind of integration pays.

Who this is for

This workflow fits a few specific roles:

  • Ancillary revenue managers who own the add-on portfolio and need evidence before greenlighting a new product line.
  • Digital product teams deciding where connectivity sits in the booking journey, from the confirmation page to the pre-flight email.
  • Partnership and business development leads evaluating connectivity providers and needing a business case to take upstairs.
  • Finance and analytics teams who will be asked the hard question: is this incremental revenue, or would those passengers have spent that money anyway?

The same format works whether you fly regional or global routes. You.ll just scale the test window and sample size.

Workflow

Here's the case study format, broken into five ordered stages. Each stage produces a specific artifact you can hand to leadership.

Stage 1: Define the hypothesis and the counterfactual

Before you sell anything, write down what you expect to happen and what you'll compare against. A strong hypothesis looks like this: "Offering a destination data plan at booking confirmation will generate at least $0.50 in incremental revenue per international booking within 90 days, without reducing attach rates of other ancillaries."

The counterfactual is the key piece. Your comparison group should be a matched set of bookings that don't see the offer, matched on route, cabin, booking window, and passenger type. Without that control group, you can't tell whether connectivity revenue is incremental or just a shift in timing.

Artifact: a one-page hypothesis document with your primary metric, guardrail metrics, and control group definition.

Stage 2: Instrument the funnel before launch

You can't measure what you don't track. Before the offer goes live, make sure your analytics capture:

  • Offer impressions, clicks, and purchases at each placement (booking confirmation, manage-trip page, pre-flight emails, app push).
  • Time from purchase to activation, and activation rate after arrival.
  • Revenue per offer shown, per booking, and per passenger.
  • Attach rates of seats, bags, and upgrades, so you can spot cannibalization.

If you're embedding connectivity through an API, this is straightforward. Celitech's developer documentation covers SDK and iframe integrations that let you drop a branded data store into your existing flow, and events fire back so you can see exactly when a traveler installs and activates. The quick start guide gets a test integration running fast.

Artifact: an analytics event map signed off by your data team.

Stage 3: Run a staged rollout

Don't flip the switch for everyone at once. Roll out in waves:

  1. Wave 1 (weeks 1-4): 10% of eligible bookings see the offer. This is your smoke test. Check for checkout friction, support tickets, and tracking gaps.
  2. Wave 2 (weeks 5-8): expand to 50%. Now you have enough volume to read conversion rates by route and destination.
  3. Wave 3 (weeks 9-12): full rollout, with the control group held back at a small percentage so you keep a live baseline.

Keep the offer, placement, and pricing identical within each wave. If you change the price mid-test, your data gets muddy and your case study loses its punch.

Artifact: a rollout calendar with wave definitions and holdout percentages.

Stage 4: Measure against the control group

At the end of the test window, compare the treatment group to the holdout on four numbers:

  • Incremental revenue per booking: connectivity revenue in the treatment group minus any revenue difference in the control group.
  • Attach rate: the percentage of offered bookings that result in a data plan purchase. This varies widely by route and destination, so your per-route breakdown matters more than a single blended number.
  • Cannibalization check: did seats, bags, or upgrade attach rates drop in the treatment group? If yes, net that out.
  • Activation rate: of passengers who bought a plan, how many actually installed and used it? Low activation means your post-purchase flow needs work, and it predicts repeat purchase behavior.

Artifact: a results table comparing treatment and control, with confidence intervals if your analytics team can produce them.

Stage 5: Write the case study in three layers

Now package it so different audiences can use it:

  • Executive summary (one paragraph): the hypothesis, the headline number, and the go/no-go recommendation.
  • Operational detail (two to three pages): funnel metrics, per-route performance, integration effort, and support load.
  • Decision appendix: methodology, control group definition, and any caveats. This protects you when someone challenges the numbers.

This layered format is what separates a case study that drives a decision from one that dies in a shared drive.

Outcomes

Run this format well and you'll walk away with three things:

  1. A defensible revenue number. Not a projection, a measured incremental figure per booking, with a control group behind it.
  2. A placement map. You'll know whether the booking confirmation page, the pre-flight email, or the app converts best, so you can double down where it works.
  3. A scaling decision. Either you expand the program, renegotiate your revenue share with your connectivity partner, or you stop with evidence instead of opinions.

Airlines and travel platforms that have run this playbook tend to find that destination-specific offers and early placement (at booking, not at the gate) drive the strongest results. The Celitech blog on eSIM ancillary revenue for airlines and travel platforms digs deeper into why the booking moment matters so much for conversion.

And if the numbers come back positive, you're not just adding a line item. You're building a habit: passengers who buy connectivity from you once come back to your app for their next trip, which compounds the revenue over time.

Frequently Asked Questions

How long should the case study test run? Twelve weeks is a solid minimum. That gives you enough booking volume and post-flight time to measure activation. If your international routes are seasonal, stretch it to cover both a peak and an off-peak window.

What's a good attach rate for pre-departure data plans? It depends on route, destination, and placement. Focus on your own per-route conversion and whether it improves as you refine placement and messaging. A 2% attach on a long-haul international route can outperform a 5% attach on short-haul domestic in pure revenue terms.

Do we need to build the eSIM experience ourselves? No. Connectivity platforms expose APIs, SDKs, and iframes so you can embed a branded data store without building telecom infrastructure. Your team focuses on placement and merchandising, not carrier agreements.

What if the results are flat? Flat results are still useful. Check whether the problem is placement (passengers never saw the offer), offer design (the plans didn't fit their trip), or activation (they bought but never installed). Each points to a different fix, and a rerun after adjusting one variable tells you more than the first test did.

Conclusion

The case study format that works for judging pre-departure travel internet sales isn't fancy. It's a controlled test with a clear hypothesis, instrumented funnel, staged rollout, and a three-layer writeup. What makes it powerful is the discipline: a holdout group, consistent pricing, and metrics that separate incremental revenue from cannibalization. Keep it tight and the results speak for themselves.

Travel connectivity is becoming table stakes in the passenger journey, and the airlines that measure it properly will price, place, and scale it smarter than the ones that guess. If you want to see what an embedded eSIM store looks like in an airline or travel platform flow, book a demo and walk through the integration and the reporting side by side.

Related Articles