Deep links for a Halyk-class SuperApp: WebView services, cross-auth, and lossless UTM/MMP attribution

Dilshat Rakhimov
May 2026 · 15 min read

A SuperApp has an unpleasant technical problem that is usually underestimated until marketing starts promoting individual products. The app can be huge: deposits, loans, transfers, utility bills, mobile top-up, tickets, insurance, eGov-like flows, partner storefronts, and dozens of WebView services. But the ad link still opens either the home screen, the last open screen, a WebView without authorization, or the correct service - but without UTM, MMP payload, and campaign context.

At the user level it looks like a small UX issue: someone clicked an ad for a deposit and landed on the generic app home. At the performance-marketing level it is a systemic failure. The campaign is buying intent for a specific product, but the app does not bring the user to that product. The algorithm gets a weak post-click signal. Attribution sees the install or open but loses the service-level outcome. The product team says ads do not work. Marketing replies that the events are firing. In reality, the route is broken.

A deep link in a SuperApp is not just a URL. It is a product API.

Why this hurts particularly hard inside a banking SuperApp

In ecommerce, a deep link usually points to a product, a category, or a checkout. In a banking SuperApp the link target is more complex:

1. The user may not be installed, installed but not authorized, authorized but without KYC, KYC-approved but not eligible for the product.
2. The right screen may be a native module, an embedded WebView, a partner domain, a mini-app, or a legacy web service.
3. The WebView may require separate authorization or a cross-token.
4. The campaign may come through Google Ads, Meta, TikTok, push, SMS, QR, email, or an MMP link.
5. Attribution parameters can live in the URL, in an MMP callback, in the Android install referrer, in SKAN/postback, in a backend click context, or in a CRM event.

If the architecture is built as "catch a link, open the app", it will not survive that many transitions. You need a link contract: stable templates, verified domains, a context ledger, an auth handoff, and rules for what parameters can travel between native and WebView.

Field observation on Halyk/Homebank: it is not only assetlinks.json

I would not write "Halyk has no App Links" in such a blanket form. A quick public check on May 4, 2026 shows a more accurate picture:

Endpoint	What you see publicly
https://homebank.kz/.well-known/assetlinks.json	Returns JSON and lists Android package kz.kkb.homebank
https://homebank.kz/.well-known/apple-app-site-association	Returns an AASA file with applinks and broad paths *, /
https://halykbank.kz/.well-known/assetlinks.json	Returns an HTML page, not Digital Asset Links JSON
https://www.halykbank.kz/.well-known/assetlinks.json	Returns an HTML page
https://www.homebank.kz/.well-known/assetlinks.json	Returns 404
https://halykbank.kz/.well-known/apple-app-site-association	Returns an HTML page, not AASA JSON

This is not a full reverse-engineering audit of the app. For that you would have to look at the Android manifest, the iOS associated domains entitlement, the MMP configuration, runtime routing, and actual device behavior. But as a public symptom this is enough: the link estate is uneven. One domain may be correctly associated with the app, while other marketing or corporate domains are not. If ad, landing, SMS, QR, or WebView links bounce between domains like these, some routes will open in the browser, some in the app, some via redirect, and some will lose parameters.

And even when a verified host is in place, that does not solve the second layer of the problem: you also need template links to specific products and services. A link like https://homebank.kz/ may technically open the app. But it does not tell the app "open the KZT deposit category", "open mobile top-up with provider_id", "open the insurance WebView and preserve campaign_id".

Verified links are layer 0, not the whole system

On Android, App Links work through intent filters and Digital Asset Links. Android verifies the hosts listed in intent filters and looks for a file at https://hostname/.well-known/assetlinks.json. If the host fails verification, the system falls back to ordinary intent resolution and the link may land in the browser or open a chooser.

On iOS, Universal Links require the Associated Domains entitlement and an apple-app-site-association file on each domain or subdomain that the app declares as applinks:. Apple specifically warns that different subdomains need their own association files, and that redirects for AASA hosting are not supported. This matters for banks: example.kz, www.example.kz, go.example.kz, online.example.kz, pay.example.kz are different hosts, and you cannot rely on a single file to magically cover them all.

Minimal Android contract:

Minimal assetlinks.json:

Minimal AASA:

But in a SuperApp this is not enough. If go.bank.kz opens the app and from there the app cannot parse deposit_category, provider_id, service_id, campaign_id, ctx, and auth state, a verified link just becomes a fancy entry into the home screen.

Link contract: product templates instead of URL chaos

A SuperApp with hundreds of services should not support hundreds of random deep links. You need a small, versioned grammar:

A good set of templates:

Marketing examples:

Rules:

1. The path describes the destination: product, category, service id, merchant id.
2. The query describes campaign context, filters, and safe UI hints.
3. Never put national ID (IIN), card number, account number, contract number, phone, loan amount, private account id, or any PII in the URL.
4. For sensitive details use ctx or state: a short opaque ID that the server resolves after authorization.
5. Every template has an owner, a schema for parameters, a fallback, an analytics event, and a QA status.

The deep-link registry should not live in Notion or in the head of one mobile developer. It should be a managed config:

Cross-authorization: where parameters get lost most often

The most common SuperApp failure looks like this:

1. The user clicks an ad: ...?utm_campaign=deposit_kzt&deep_link_value=deposit_term.
2. An App Link opens the app.
3. The user is not authorized.
4. The app sends them into login or KYC.
5. After login the auth service returns the user to the default home.
6. utm_*, deep_link_value, service_id, return_to, and MMP attributes are already gone.

Or the other variant:

1. The app opens a service WebView.
2. The WebView requires its own token.
3. The cross-auth endpoint performs a redirect.
4. The redirect does not pass query params through.
5. The service opens, but the campaign context never reaches the purchase event.

The solution is not to drag every parameter through every redirect. For that you need a context ledger.

Architecture:

The point of ctx_id: it has to survive every transition. Raw UTM can be lost, the MMP callback may arrive later, the install referrer may only appear on first open, the WebView may launch after login. But ctx_id ties all of this into a single record.

Example record:

If the user is already authorized, the app router opens the destination immediately. If not, it stores the ctx_id, sends the user into login/KYC, and after success returns them not to home but to the same route target.

MMP and UTM: do not conflate routing and attribution

One reason SuperApp teams break deep links is that they try to use a single URL to solve two different jobs:

1. Routing: where to open the user.
2. Attribution: where the user came from.

These layers are related but not identical. deep_link_value=deposit_term may be a routing signal. utm_campaign=deposit_kzt_may is campaign reporting. af_sub1=deposit is an MMP sub parameter. gclid or gbraid is an ad click identifier. provider_id=mobile-kcell is a product target. You cannot just shovel all of this into every service, and you cannot afford to lose any of it at login.

For AppsFlyer OneLink, the installed-user UDL flow can return deep_link_value, deep_link_sub1-10, and parameters from the link. But for new users, privacy protection limits the payload: you cannot count on receiving every campaign field, such as media source and campaign, in the deep-link callback after install. Adjust has a similar split between link parameters, deep_link, and custom label/redirect logic. So the app router has to be able to merge multiple sources:

Source	What it provides	How to use it
Open URL	Path, query, ctx, UTM, click ids	Primary routing for installed users
MMP callback	deep_link_value, sub params, attribution metadata	Deferred routing and attribution enrichment
Android Install Referrer	Referrer URL from Google Play	Android install attribution fallback
Backend click context	Normalized campaign params and destination	Source of truth for cross-auth and WebView
Firebase/GA4 events	App open, screen, product event	Measurement and audience building

Merge rule:

A side note: do not start new projects on Firebase Dynamic Links. Firebase officially deprecated Dynamic Links, with shutdown scheduled for August 25, 2025. For installed-user deep linking use App Links and Universal Links directly. For deferred deep linking and paid attribution, use an MMP or your own link gateway with a clear fallback, but do not build a new system on FDL.

WebView services: how not to lose context inside a mini-app

A WebView inside a SuperApp often lives as a separate product within the product. It can have its own backend, its own sessions, a partner order id, and its own analytics script. If the native app simply opens:

the context is almost guaranteed to be lost. You need a handoff:

Requirements for the handoff token:

1. Short TTL: minutes, not days.
2. Audience-bound: only the specific service id.
3. Return path signed: the WebView should not decide on its own where to send the user back.
4. No raw PII: the token may point at a server-side subject but must not reveal IIN, phone, or account number.
5. Event correlation: the token contains or allows lookup of an event_id / ctx_id.

When the WebView completes an action, it should return the event to native/backend:

But the final measurement event should be confirmed by the backend:

Otherwise the purchase can land in analytics before the payment has actually been confirmed.

What links should look like for deposits, payments, and services

Bad link:

It is not addressable. The ad platform does not know which product was promoted. The app does not know where to send the user. BI then tries to guess intent from the campaign name.

Weak link:

It is better, but the category, currency, offer id, route fallback, and attribution context are missing.

Acceptable link:

For payments:

For a WebView service:

For an MMP OneLink you can hold the route in deep_link_value, and the parameters in sub fields:

But the app still has to normalize this into its own route:

What to do when the app is not installed

If the app is installed, a verified link should open it. If it is not installed, the link should open a fallback: App Store, Google Play, or a web landing page. An MMP is usually helpful here because it can route-by-platform and supports deferred deep linking.

But you cannot count on the App Store or Play Store preserving the full URL verbatim. On Android there is the Install Referrer API, which can return the referrer content from Google Play. On iOS, the direct referrer through the install flow is fundamentally limited, so deferred deep linking mostly relies on MMP attribution matching and a privacy-safe payload.

The right model:

1. For installed users - App Links / Universal Links.
2. For not installed - an MMP link or link gateway with a store fallback.
3. For deferred routing - deep_link_value + sub params, not a hope of a full raw URL surviving install.
4. For paid attribution - MMP/ads integration, not a homemade UTM spreadsheet.
5. For bank compliance - consent-aware storage and deletion of click context.

QA matrix: how to know deep links actually work

You should not just test "the link opens the app", you should test the whole route.

Scenario	Expected result
Installed + logged in	Opens the exact product screen
Installed + logged out	Login, then the same product screen
Installed + KYC missing	KYC flow, then return_to or a clear eligibility fallback
Not installed Android	Store install, first open, deferred route
Not installed iOS	Store install, first open, MMP deferred route where available
WebView service	Cross-auth token is present, ctx is preserved, service event returns
Expired WebView token	Refresh/handoff retry, not home screen
Invalid provider_id	Controlled fallback to category screen
utm_* + MMP params	Context ledger holds both layers
Sensitive params in URL	Link rejected or sanitized

Commands for technical QA:

Checks:

1. Status 200.
2. No redirect for association files.
3. Correct JSON body.
4. Correct content type where the platform expects it.
5. Every claimed host has its own file.
6. Production app id/package and signing certificate are present.
7. Dev/staging app ids do not accidentally shadow production behavior.

Android test:

iOS test:

1. Add the URL to Notes.
2. Long-press it and verify that iOS offers to open in the app.
3. Use Associated Domains diagnostics in Developer settings.
4. Check that directly typing a URL into Safari's address bar is not treated as proof of Universal Link behavior. Apple documents that entering a URL directly into the address bar does not open the app as a Universal Link.

Measurement events

Deep-link success should be measured separately from product success.

In BigQuery you should be able to answer:

1. Which campaigns lose the route most often after auth?
2. Which WebView services open but never return a callback?
3. Where are most invalid provider ids coming from?
4. Which utm_campaign values produce deeplink_received but not deeplink_opened?
5. How many product purchases carry a ctx_id, and how many look organic because the context was dropped?

What I would force a SuperApp team to do in 30 days

1. Pick a canonical link domain: for example go.bank.kz, or a verified homebank.kz, but without mixing in non-associated host variants.
2. Configure App Links / Universal Links for production, staging, and dev separately.
3. Remove marketing links from domains whose association endpoints return HTML/404.
4. Build a registry of deep-link templates for deposits, payments, transfers, loans, cards, marketplace, services.
5. Add a ctx_id ledger and stop carrying sensitive context in the query string.
6. Rebuild login/KYC flow so that state=ctx_id survives auth.
7. Implement a WebView handoff token and a return_to contract.
8. Normalize MMP payloads into the same route contract.
9. Log deeplink_received, deeplink_resolved, deeplink_opened, deeplink_failed.
10. Build a QA dashboard for route loss, auth loss, WebView callback loss, and attribution loss.

The main point

If a SuperApp cannot open a specific deposit, payment, loan, or WebView service through a stable link, marketing is doomed to optimize toward an abstract app open instead of a product. If cross-authorization loses URL parameters, a paid campaign can deliver the right user but the purchase event will look like organic or generic app usage. If the MMP payload lives separately from the native router, deferred deep linking becomes a matter of luck.

Deep linking in a SuperApp should be designed as growth infrastructure: verified hosts, a template registry, a context ledger, an auth-safe return path, a WebView handoff, MMP merge rules, and measurement events. Then a link from an ad, push, SMS, or QR leads not "into the app", but into the right product with the attribution context preserved.

Sources

• Android Developers: Add Android App Links
• Android Developers: Verify Android App Links
• Apple Developer: Supporting Associated Domains
• Apple Developer: Debugging Universal Links
• Firebase: Dynamic Links Deprecation FAQ
• AppsFlyer: Tracking link structure and parameters
• AppsFlyer: iOS Unified Deep Linking
• Adjust: Link parameters
• Android Developers: Google Play Install Referrer