Passing Parameters to the Destination URL or App
A common question we get from customers:
"How do I pass user-specific data — like a
userId,couponCode,productId, or campaign tag — through a Chottu deeplink to my web destination or my app?"
There are three ways to do this. Pick the one that matches how you generate and share your links — and where you need the params (web, app, or both).
Method 1 — Static params (set at link creation time)
Use this when the parameters are known when you create the link and don't change per click.
Example
When creating the link, include the parameters directly in the Destination URL:
| Field | Value |
|---|---|
| Short URL | https://abc.chottu.link/summer-sale |
| Destination URL | https://yourwebsite.com/sale?campaign=summer25&discount=20 |
You then share the short URL https://abc.chottu.link/summer-sale everywhere — Instagram, email, SMS, ads, etc.
What happens on click
- Desktop browser — user lands on
https://yourwebsite.com/sale?campaign=summer25&discount=20. - Mobile (app not installed) — user is taken to the App Store / Play Store. After installing and opening the app, the SDK fires a callback with the full destination URL including all params (
campaign=summer25&discount=20) so your app can route accordingly. - Mobile (app installed) — the SDK resolves the link directly and surfaces the same destination URL with all params.
Best for campaign-level or link-level data — e.g., one link per campaign, one link per product page, one link per influencer. The params are baked into the link itself.
Because each variation is its own deeplink, you get per-link analytics out of the box. Clicks, installs, conversions, attribution, and country/device breakdowns are tracked separately for every link — making it easy to compare performance across campaigns, products, or influencers in your dashboard.
Method 2 — Dynamic params via _ch_incp=1 (set at share time)
Use this when you want one deeplink that carries different params per share — for example, a referral link that includes the sender's userId, or a generic product link that carries a per-user coupon.
Example
Create a single deeplink with a plain destination URL (no params needed):
| Field | Value |
|---|---|
| Short URL | https://example.chottu.link/summer-sale |
| Destination URL | https://yourwebsite.com/ |
Now, when you share the link, append your params plus the magic flag _ch_incp=1 to the short URL:
https://example.chottu.link/summer-sale?userId=1234&_ch_incp=1
https://example.chottu.link/summer-sale?userId=1234&couponCode=WELCOME10&_ch_incp=1
_ch_incp=1 is the trigger — it tells Chottu to copy all the other query params from the click URL onto the destination URL.
What happens on click
- Desktop browser — user lands on
https://yourwebsite.com/?userId=1234&couponCode=WELCOME10. The trigger param_ch_incpis stripped automatically. - Mobile (app not installed) — user goes to the store, installs the app, and on first launch the SDK fires a callback with the destination URL already containing the click params (
userId=1234&couponCode=WELCOME10). This works even though the user installed the app after the click. - Mobile (app installed) — the SDK resolves the link and the destination URL surfaced to the app contains the click params.
Best for per-user or per-share data — e.g., referral codes, user IDs, dynamic coupon codes, A/B test variants. One link, infinite variations.
_ch_incp=1 flag is requiredWithout _ch_incp=1, the click URL's query params are not forwarded to the destination. This is intentional — it prevents accidental leakage of tracking params that you may not want on your destination URL.
✅ https://example.chottu.link/summer-sale?userId=1234&_ch_incp=1 → userId reaches destination
❌ https://example.chottu.link/summer-sale?userId=1234 → userId is dropped
Because all shares use the same single deeplink, every click, install, and conversion is rolled up under that one deeplink's analytics in your dashboard. You will not see per-share breakdowns natively for whatever params you pass (e.g. userId, couponCode, referrerId, etc ; any custom param works the same way). Those distinctions live in the click URL params, which you can capture in your own backend (the params reach your destination URL and your app callback).
If you need per-variation analytics inside the Chottu dashboard, use Method 1 instead.
Method 3 — Read the raw click URL inside your app via shortLinkRaw (App SDK only)
This method is available exclusively inside our mobile App SDKs (iOS, Android, etc.). It is not available on desktop browsers, on the web, or anywhere outside an SDK-integrated app. If you need params on the web destination, use Method 1 or Method 2.
Every link-received callback fired by our App SDKs exposes a field called shortLinkRaw — this is the exact deeplink URL that was clicked, with all the original query parameters intact.
You don't need _ch_incp=1 for this. You don't need to put params on the destination URL. Whatever you appended to the share URL is delivered to your app verbatim, and you can parse it however you like.
Example
User clicks (or taps):
https://example.chottu.link/summer-sale?userId=1234&couponCode=WELCOME10
In your app's link-received callback, you'll receive (alongside the resolved destination URL and other fields):
shortLinkRaw = "https://example.chottu.link/summer-sale?userId=1234&couponCode=WELCOME10"
You can then parse out userId and couponCode (or any other params you passed — these are just examples; any custom param works) using your platform's URL utilities, and route the user inside your app accordingly.
Best when only the app needs the params and you don't want to expose them on your web destination URL — e.g., a referral handshake that's purely in-app, or app-specific routing keys you don't want in your web logs.
It's also useful as a fallback even when you're using Method 1 or 2 — if you ever need the original click URL exactly as it was tapped (for debugging, audit logs, or custom routing logic), shortLinkRaw is always there.
Same behaviour as the underlying link — analytics are tracked at the deeplink level. shortLinkRaw is just a field on the SDK callback; it doesn't change how clicks/installs are bucketed in your dashboard.
Comparison — at a glance
| Method 1 — Static | Method 2 — _ch_incp=1 | Method 3 — shortLinkRaw | |
|---|---|---|---|
| Where params are set | At link creation, in destination URL | At share time, in short URL | At share time, in short URL |
| Number of links needed | One per param-combination | One link, many variations | One link, many variations |
| Best for | Campaigns, product pages, fixed segments | Referrals, per-user data, dynamic coupons | App-only routing / data the web shouldn't see |
Requires _ch_incp=1? | No | Yes | No |
| Works on desktop / web? | ✅ | ✅ | ❌ — App SDK only |
| Works on mobile (deferred install)? | ✅ | ✅ | ✅ (via SDK callback) |
| Works on mobile (already installed)? | ✅ | ✅ | ✅ (via SDK callback) |
| Params reach destination URL? | ✅ | ✅ | ❌ (params stay in shortLinkRaw, not appended to destination) |
| Analytics granularity | Per-link — separate clicks/installs/conversions for each link | Single bucket — all shares roll up under one deeplink's analytics | Single bucket — same as Method 2 |
Combining the methods
Method 1 + Method 2 — how params merge into the destination URL
If your destination URL already has params (Method 1) and you also pass _ch_incp=1 with click-time params (Method 2), the merge order on the final destination URL is:
destination's own params < link's UTM config < click pass-through (last wins)
Example:
| Value | |
|---|---|
| Destination URL | https://yourwebsite.com/sale?campaign=summer25 |
| Click URL | https://example.chottu.link/summer-sale?userId=1234&campaign=instagram&_ch_incp=1 |
| Final URL | https://yourwebsite.com/sale?campaign=instagram&userId=1234 |
Notice that campaign was overridden by the click-time value (instagram won over summer25).
Method 3 sits alongside — it's always available in the App SDK
Method 3 (shortLinkRaw) doesn't participate in the merge above — it isn't appended to the destination URL. Instead, the raw clicked deeplink URL is always delivered to your App SDK callback regardless of which methods you used. So you can:
- Use Method 1 or 2 to control what reaches your web destination and what your app receives as the resolved destination URL.
- And independently read
shortLinkRawinside the app to recover the exact URL that was tapped, with all original params intact.
This is useful when you want some params on the destination URL and want the original raw URL for in-app logic / debugging.
FAQ
Q: Will _ch_incp=1 itself appear on my destination URL?
No — the trigger key is always stripped before forwarding.
Q: What values are accepted for the trigger?
Only the literal string 1. Values like _ch_incp=true, _ch_incp=0, or _ch_incp=yes will not activate pass-through.
Q: Are URL-encoded values handled correctly?
Yes — values are decoded on receipt and re-encoded when appended to the destination URL. Spaces, @, &, unicode, etc. all round-trip cleanly.
Q: What about repeated keys (e.g., ?tag=a&tag=b&tag=c)?
All values are preserved in order on the destination URL.
Q: Does this work for deferred deeplinks (mobile install attribution)? Yes. The click URL's params are captured at click time and replayed when the SDK resolves the deferred match after install.
Q: Can I use Method 3 (shortLinkRaw) on the web?
No. shortLinkRaw is exposed only via the App SDK link-received callbacks (iOS, Android, etc.). For web destinations, use Method 1 or Method 2.