Landing Pages Builder, Explained: SMS to Short Link to Attributed Conversion

Quick answer: An SMS or WhatsApp travel-sized message converts better when the link at the end opens a focused destination page, not a homepage. The Messages → Landing Pages hub in Devotel Orbit gives a campaign that destination without standing up any infrastructure: assemble a mobile page from content blocks (hero, product grid, opt-in form, coupon), publish it, and the platform mints a trackable short link on your shortener. Every visit and every conversion — an opt-in submit, a coupon claim, a CTA click — is recorded against the exact message or campaign the recipient came from, so the loop from sent message to measured outcome closes in one place. This post walks the shipped surface end to end, names the two ways a recipient's tap can open a funnel (and when each is the right one), does the attribution math explicitly, and situates the builder against the click-to-WhatsApp entry point and against shipping recipients to a hosted microsite instead.

What the shipped surface actually does

The builder lives on the Messages → Landing Pages dashboard surface and over the `/api/v1/links/landing-pages` endpoints, with one lifecycle per page:

1. Draft. Create a page with a title, an optional slug, and a block list. Drafts save with zero blocks — a work-in-progress page is legal, private to your tenant, and has no public URL.
2. Build from four block types. A page is a theme (optional accent and background colors) plus up to 50 blocks: hero (headline, subheading, image, CTA), product_grid (1–24 products with prices and links), opt_in_form (1–3 fields of name / email / phone, with your consent text), and coupon (a claimable code with an expiry).
3. Publish. One click or one POST .../publish call. The platform mints a standard 6-character short code on the same shortener that powers POST /api/v1/links — the page's short_url respects your branded short domain and inherits the full click pipeline (bot-vs-human click scoring, per-contact click history, the short_link.click webhook). Publish is idempotent: re-publishing keeps the existing short link, and content edits go live under the same URL.
4. Measure. The rendered page records a visit when a recipient opens it and a conversion on an opt-in submit, a coupon claim, or a CTA click. The dashboard card shows the live counters; the analytics endpoint (GET .../analytics) returns totals plus by_campaign, by_message, and recent-conversion breakdowns.

Rendered pages ship as a single self-contained, server-side HTML document with no client-side JavaScript, and every operator-supplied string is HTML-escaped — a page definition cannot inject markup into a recipient's browser. Writes (create, update, publish, delete) are restricted to owner, admin, and developer roles on both the dashboard and the API; viewers can list pages and read analytics.

For the request/response schemas and the troubleshooting table, the Landing pages guide is the operator reference.

Two entry points into a funnel — and when each opens it

A recipient's tap can open a funnel in two structurally different ways, and Orbit treats them as siblings, not substitutes:

• Click-to-WhatsApp (Meta-ads entry point). The tap is paid Meta inventory — a Facebook or Instagram ad whose primary action opens a WhatsApp conversation with your business. Meta opens a 72-hour free entry-point window, the inbound lands in the shared Inbox with the source ad attached, and attribution is ad → conversation. This entry point is for demand paid on Meta's auction where the conversation itself is the destination. The click-to-WhatsApp post covers the six-stage flow, the meta_ads channel card, and the failure modes.
• SMS/WhatsApp deep-link short URL (this builder). The tap rides a message you already sent — an SMS, WhatsApp, or RCS campaign carrying a tracked short link — and opens a page you own. Attribution is message → page visit → on-page conversion, with no ad platform involved. This entry point is for demand you already have permission to reach and need to move from a 160-character body to a full offer surface.

The decision is the source of traffic, not the tooling: CTWA buys cold reach and opens a conversation; the short-link-to-page loop converts the list you already built. A mature program runs both — paid entry points refill the opt-in list, and the landing-page loop is what that list's next campaign points at.

The attribution math — from sent message to conversion

The contract is stated on the surface itself: visits and conversions are attributed to the sending message or campaign. Mechanically, it works like this:

1. The page's short link is a first-class tracked link. Publishing mints a short code through the same shortener every other campaign link uses, redirecting /l/:code to the page's internal render. So the first count — the click-through on your message — lands in the same click-tracking funnel you already read (short_link.click webhook included), before landing-page events even start.
2. Every page event carries the attribution tuple. A recorded visit or conversion stamps {campaign, message, contact} at write time. Nothing downstream has to join page activity back to sends — the by_campaign and by_message rollups answer "which sends drove page activity" directly.
3. A conversion is a named, valued event. Conversion kinds (opt_in, coupon_claim, cta_click) each record their kind, the converting contact when known, and a value — the submitted email or the claimed coupon code. recent_conversions on the analytics endpoint returns them as inspectable events, not just a counter.
4. It feeds campaign ROAS. A page visit is the downstream of the message's tracked click — the engagement rung of the funnel — and a conversion is the measurable action the campaign paid for. The same events surface in campaign ROAS reporting alongside tracked clicks, so send cost, engagement, and attributed outcomes sit in one report.

Aggregation is deliberately bounded (up to 50,000 recent events per page feed the rollup), which keeps per-page analytics fast even on high-traffic pages.

The short-domain posture is yours, not the platform's

There is no platform-mandated short domain for landing pages. A published page's short URL is minted through the standard shortener, which means it resolves your tenant-configured branded short domain — a vanity host you set in your organization settings — exactly as every other tracked link you create. Tenants who have not set a branded domain fall back to the cert-valid default the shortener already uses; tenants who have one see page links on their own host. The assignment is a tenant-owned control: Orbit never overrides it for landing pages, and the page's render and analytics paths are identical either way. The only thing the platform fixes is the tracking — the brand on the URL is yours.

A worked example: first 200 visits of a flash-sale SMS

A DTC retailer runs a 48-hour flash sale to its SMS list.

1. Draft. Open Messages → Landing Pages, create a page titled "Flash sale – 25% off," and assemble three blocks: a hero with the offer and a "Shop the sale" CTA, a product_grid of the six featured items, and a coupon block with the code FLASH25 and Sunday's expiry. The page sits in draft — nothing public yet.
2. Publish, link, send. Publish mints the short URL. Paste it into the campaign's SMS body: "FLASH25: 48 hours, 25% off sitewide. Shop: <short link>" — and send the campaign to the segment. (In practice the platform also auto-shortens long URLs in message bodies through the same links surface, but a published LP link is already short.)
3. Watch the funnel close. Recipients tap, the tracked click fires on the message, and each page open records a visit. Say the first 200 visits arrive over the sale window. Of those, 41 recipients tap the CTA or claim FLASH25 — 41 conversion events, each stamped with the campaign, the message, and (for coupon claims) the code itself.
4. Read it back. The page's analytics shows visits: 200, conversions: 41, a per-campaign row naming the flash-sale campaign, and the recent-conversions feed at event granularity. The campaign's attribution panel shows the same 200/41 engagement rung next to click-through — one funnel from send to claimed coupon, with no export-stitching.

The print-side sibling of this same attribution loop is the QR-code generation post: a QR on the packing slip encodes the same kind of tracked destination and answers "which physical surface produced the conversation" — the landing-page loop answers it for the campaign queue.

Versus shipping recipients to Shopify, WooCommerce, or any hosted microsite

The natural alternative is "send them to the store." Each posture wins somewhere:

• Hosted commerce destination (Shopify, WooCommerce storefront). Right for breadth — full catalog, cart, checkout, product reviews. The costs are attribution and speed: the storefront's analytics start at session arrival, not at the message; closing the loop back to the exact sending SMS/RCS usually means a UTM scheme plus stitching two reports, and a heavyweight theme page on a connection that just came out of an SMS. (Our Shopify and WooCommerce guides cover the commerce-platform pairing itself — that pairing and the LP builder solve different problems.)
• External microsite tool (Linktree-class). You own tracking on their domain, with their subscription and a second analytics silo; the message-side attribution still stops at the click.
• The no-code LP layer (this builder). Purpose-built for the campaign destination: the page is one tap of focused content, the click and the on-page conversion share one attribution spine, and nothing extra has to be hosted, themed, or maintained. Publishing inherits your branded short domain, so the recipient never leaves your brand orbit.

The practical split most teams land on: campaign destinations that need the full catalog go to the storefront; campaign destinations that exist to convert one offer go to a landing page. The second case is most of them.

Frequently asked questions

Can I use my own HTML or a custom template?

Not today. A page is the four block types — hero, product grid, opt-in form, coupon — over an optional theme (accent and background colors). That constraint is deliberate: it is what lets pages render as a self-contained, escaped, script-free document. If you need bespoke markup, host it as a storefront or microsite and drop a tracked short link to it instead — you lose on-page conversion events but keep click attribution. The builder surface uses a JSON content model rather than HTML by design.

Can I A/B test two pages?

There is no built-in split-testing on a single short URL. The deterministic version is to publish two pages (A and B variants), mint both short links, and segment your recipients between them — visits and conversions then roll up per page and per message, and you compare like with like in each page's analytics.

Are pages multilingual?

Blocks are author-supplied strings, so publish one page per language — there is no per-viewer locale switch. The actual translator's dilemma lives in the sending message, which is where the localized-template playbook covers per-locale regimes; pairing a localized campaign body with a same-language landing page is the pattern that keeps the funnel coherent.

What is the conversion-source match rate — will every visit actually attribute?

Events are stamped at write time from the render request's context: the platform records what the click carried. A recipient who arrives via the campaign short link attributes to that message/campaign; a recipient who lands by some other path (a forwarded link opened fresh, direct traffic to the render URL) is counted as a visit with no source attribution, and the totals still reflect them. by_message/by_campaign rows only ever claim what actually carried the tuple, so the breakdowns never overclaim.

What happens if I edit a page after publishing?

Edits go live under the same short URL — publish stays idempotent and the short link never changes. To retire a page without losing its event history, archive it; deleting removes the page's visit and conversion events with it.

Where to start

• Build a page: Messages → Landing Pages in the dashboard — draft, publish, drop the short link into your next SMS or WhatsApp campaign.
• Read the operator reference: Landing pages guide — block library, publish semantics, analytics payload, and the troubleshooting table.
• Pair the siblings: the click-to-WhatsApp explainer for the paid entry point into conversations, the QR-code post for the print-side attribution sibling, and campaign ROAS attribution for where the page's engagement rung feeds the revenue math.