How to build a smart link
platform.

A smart link system is easier to reason about when it is split into four layers: creation, redirect, event capture and analysis. Creation is where a user chooses a destination and code. Redirect is the public path that resolves that code. Event capture records what happened. Analysis turns those records into totals, dimensions and trends.

Keeping those concerns separate matters. A marketing dashboard can become more sophisticated without changing the public redirect contract, while QR codes and profile cards can reuse the same redirect and event infrastructure instead of implementing analytics again.

On each public request, Kompi resolves the short code against an active link record, normalises the target URL and returns an HTTP 302 redirect. If the code does not exist, it returns a 404. If the stored destination is invalid, the request fails instead of sending the visitor somewhere unpredictable.

The important resilience decision is that analytics are treated as best-effort. Kompi attempts to create the click event and increment the link total, but the redirect does not depend on those writes succeeding. A temporary analytics failure should not turn a working campaign link into a dead link.

A single clicks integer is useful for quick totals but cannot answer most marketing questions. Kompi therefore keeps both an aggregate click count on the link and individual click-event records underneath it.

Event records can carry UTM source, medium, campaign, term and content, plus the raw referrer, a normalised referrer host, user agent and geographic fields. The aggregate count is cheap to display; the event table is what makes segmentation possible.

A link can receive UTMs in two places: on the short URL itself or already embedded in the destination URL. Kompi checks the short-link request first. If a parameter is absent there, it falls back to the destination.

That order is practical because it lets one managed destination support different placements. A creator can keep a canonical destination but issue separate short URLs for an email, QR poster, social profile or paid campaign without duplicating the page behind them.

Raw referrer values are messy. Social apps may send app-style schemes, browsers may provide full URLs and some visits arrive with no useful referrer at all. Kompi normalises known hosts into readable sources such as Instagram, TikTok, YouTube, LinkedIn, Reddit, Google and X, while preserving a sensible fallback for direct or unknown traffic.

Geography is captured from edge or hosting-provider headers when available. The current route can use country, region and city values supplied by the edge, which means the redirect handler does not need to make a separate geolocation API request before sending the visitor onward.

A QR code generator on its own produces an image. A QR feature inside a smart link platform produces a measurable entry point. The stronger architecture is therefore QR → managed link → destination, rather than QR → destination directly.

That pattern means the same analytics model can be used for links shared online and codes printed in the physical world. It also leaves room for dynamic destinations: the printed code stays the same while the managed link can change where it sends people.

A production link platform needs an ownership model. In Kompi, links belong to workspaces rather than floating around as isolated records. The same workspace can also own bio pages, KR Codes, contact forms, subscriber lists, engagement events and other product tools.

That gives the application one consistent place to enforce access, plan limits and billing. Authentication is handled separately from public redirects: users sign into the product, while visitors should be able to follow a public link without participating in the account system at all.

Event capture is backend infrastructure; the dashboard is the product. Totals should answer the first question quickly, then let users move into dimensions such as source, campaign, place or time. The trick is not to show every field simply because it exists in the database.

Kompi also combines first-party link events with broader product analytics tooling. Those are different jobs: product analytics helps understand how users operate Kompi itself, while click events explain what happens to the links and campaigns those users publish.

1. 01Model users, workspaces and link ownership before adding advanced features.
2. 02Create a public redirect route that resolves only active links and validates destinations.
3. 03Store an aggregate click count plus event-level records for analysis.
4. 04Define your attribution rules for UTMs before campaigns start creating inconsistent data.
5. 05Normalise referrers into a small set of useful sources while retaining a fallback.
6. 06Capture edge-provided geographic context without blocking the redirect on a third-party lookup.
7. 07Make QR codes point into the managed link layer so physical and digital campaigns share analytics.
8. 08Keep authenticated dashboard routes separate from public redirect traffic.
9. 09Add billing and plan limits at the workspace level rather than feature by feature.
10. 10Design analytics around decisions users need to make, not around every column you can query.