Skip to main content
Attribution answers one question: which creator caused this sale? Every answer lands in one ledger table (attribution_events) that records how it was resolved and how much to trust it, so confirmed revenue and modeled revenue never blur together.

​
The two ways credit travels

A creator shares a vanity URL like tryapp.link/jane. EVO records the click, mints a click token (evc_…), and forwards the visitor.
  • Web: the visitor lands on the brand site with ?evo_cid=evc_…. The EVO pixel stores that token and attaches it to the purchase.
  • App: the visitor gets a smart install page that copies the token to the clipboard, then opens the App Store or Google Play. On first launch the SDK sends the token back, and the install is matched deterministically.
  • No token: for app links only, EVO falls back to matching the install against the previous 24 hours of clicks by hashed IP and platform.

​
Codes

A creator says “use code JANE10”. The customer types it at checkout or into the app, and the pixel or SDK sends it with the purchase. A code is the only path that survives word of mouth, podcasts, and screenshots — nothing has to be clicked. Codes are per brand, so another brand’s JANE10 never credits across.

​
What a brand sees

In the client portal under Results → Attribution: The list never exposes another brand’s data, raw creator user ids, or pixel keys outside the setup section. Link creation stays an EVO team action.

​
Confidence levels

Every ledger row stores a resolution_method and a confidence between 0 and 1. Payout-grade means the method is in AttributionEvent::CONFIRMED_METHODS (code, link, clipboard, subscription_inherit). ip is deliberately excluded: a shared NAT or office network is useful for reporting but is not evidence strong enough to pay a creator on.
A code sits a notch below a click token on purpose. It is deterministic, but a code can be reshared by someone other than the creator who earned it.

​
Resolution order

An install resolves on the first rung that hits: clipboard token → creator code → hashed IP match → unattributed. A purchase resolves: click token → creator code → the attribution its matched install already resolved → unattributed. An inherited purchase copies the install’s link, creator, code, resolution method, and confidence.

​
Which setup do I need

​
Source code and packages

Everything a developer integrates is public. Open an issue on the repository if something in the SDK or pixel does not behave as documented.

SDK repository

Swift Package, React Native package and the web pixel source, with CI and release notes.

npm package

@evomarketing/attribution-react-native, published from the repository on every tagged release.

Swift Package

Add the repository URL in Xcode and import EVOAttribution. iOS 15 and later.

​
Where to go next

Links and domains

Link anatomy, the smart install page, and connecting your own domain

Creator codes

Codes that survive word of mouth

EVO pixel

One script tag and one purchase call

Mobile SDK

iOS and React Native drop-ins

Billing connectors

RevenueCat, Superwall, Stripe, Shopify, Apple

API reference

Public, portal, and internal endpoints

​
Privacy

EVO never stores raw visitor IPs for this flow. It stores secret-keyed SHA256 hashes, only on app-link clicks, and reads them only inside the 24-hour install-matching window. Attribution::PurgeClickIpHashesJob runs hourly and nulls both hash columns on any click older than that window, so the hashes never outlive the one job that reads them. Web-link clicks leave both fingerprint fields empty.