Klikdata waarop je écht kunt query'en.
Jij meet attributie, funnel-afhaak en incrementele lift. Elido slaat elke klik op in een kolomgeoriënteerde analytics-store met ruwe toegang - geen sampling, geen vertraging door aggregatie.
- Geen kliksampling op welke tier dan ook - elk event opgeslagen
- Analytics-DSN per workspace, alleen-lezen, roteerbaar
- Ingeplande S3- + BigQuery-export (standaard Parquet)
- Ruwe klik-events via webhook-firehose / Kafka-consumer
Hoe klikdata binnenkomt
Klik → eventstroom → analytics-store, zonder aggregatie ertussen.
De meeste shorteners geven je een teller. Wij geven je een rij per klik, binnengehaald in minder dan vijf seconden, opvraagbaar vanuit je eigen SQL-client. De pipeline is één binary die naar één Kafka-compatibel topic schrijft, dat door één consumer wordt leeggemaakt naar de analytics-store - geen aggregatieservice, geen dagelijkse samenvattingen, geen voetnoot over 'sampling na 10K'.
- Step 1
Click
elido.me/x → 302Edge POP returns the destination + emits an event to our event stream.
- Step 2
Event stream
topic: clicks.<workspace>12 partitions, at-least-once delivery, 7-day topic retention.
- Step 3
Analytics store
<5s p99 ingest lagOur ingestion service drains the topic into the per-workspace events table.
- Step 4
Your tools
DSN · BigQuery · KafkaRead-only DSN, scheduled Parquet export, or direct firehose consumer.
Analytics-DSN per workspace
Een alleen-lezen DSN die je direct in Metabase kunt plakken.
Business-workspaces krijgen een alleen-lezen analytics-DSN per workspace, gescoopt op hun event-tabel via row-level security. Sluit hem aan op Metabase, Hex, Apache Superset, Grafana, of elke compatibele SQL-/BI-client. De DSN is roteerbaar vanuit de workspace-instellingen zonder de onderliggende tabel te wijzigen.
- Stabiel schemaVersioned in /docs/api-reference; migratiegidsen in /changelog
- Row-level securityDSN uitsluitend gescoopt op de event-rijen van jouw workspace
- Compatibel met BI-toolsMetabase, Hex, Superset, Grafana, Looker - alles wat SQL spreekt
- Queries onder de secondeTabellen met 1B rijen onder 1s voor typische group-by-land / uur-aggregaties
SELECT country, COUNT(*) AS clicks
FROM events
WHERE link_id = 'lnk_8a2fc1...'
AND occurred_at >= now() - INTERVAL 7 DAY
GROUP BY country
ORDER BY clicks DESC
LIMIT 5;| country | clicks | distribution |
|---|---|---|
| DE | 18,429 | |
| FR | 12,184 | |
| ES | 9,847 | |
| IT | 8,213 | |
| PL | 7,062 |
Geografie die de export overleeft
Landniveau-dichtheid op elke klik - geen gehashte bucket.
Elk klik-event bevat land (ISO 3166-1 alpha-2), regio en stad, herleid uit een offline geo-IP-dataset op edge-niveau. Het IP-adres zelf wordt vóór opslag afgekapt tot /24 (IPv4) of /48 (IPv6), zodat geo-data behouden blijft maar PII niet. Hieronder zie je in de UI dezelfde data die ook in je warehouse terechtkomt - geen aggregatielaag ertussen.
Source of truth. 0% sampling, 24-month retention on Business.
Hourly buckets, snappy-compressed Parquet (or JSON if you prefer).
Native BigQuery Transfer service or Snowflake external table loads from S3.
Warehouse-export
Elk uur Parquet naar S3, daarna een native overdracht naar je warehouse.
De ingeplande export verstuurt klik-events als Parquet naar je S3-bucket, elk uur of dagelijks; native BigQuery Transfer of een externe Snowflake-tabel laadt het vandaar. De eerste run is een volledige backfill tot aan je bewaartermijn; volgende runs voegen alleen nieuwe events toe, gesleuteld op de event-timestamp. Mislukte pogingen worden opnieuw geprobeerd; er gaat een dead-letter-melding uit als een batch niet binnen 2 uur landt.
- Parquet (standaard) of JSON; één object per uur-bucket
- Filter de export op domein, campagne of link-tag
- Native BigQuery Transfer + externe Snowflake-tabel
- Dead-letter-melding bij batchfout van >2u
- Kafka-firehose voor levering onder de seconde (Business)
Wat je kunt doen
- Geen kliksampling op welke tier dan ook - elk event opgeslagen
- Analytics-DSN per workspace, alleen-lezen, roteerbaar
- Ingeplande S3- + BigQuery-export (standaard Parquet)
- Ruwe klik-events via webhook-firehose / Kafka-consumer
- Querylatentie onder de seconde op tabellen met 1B+ rijen
- Server-side klikattributie met click-ID-deduplicatie
Wat 'analytics-first' betekent in het datamodel van Elido
De meeste shortener-analytics zijn samengevoegde totalen. Onderstaande functies leggen uit wat er verandert wanneer de ruwe klikstroom het primaire artefact is, niet een samenvatting.
Elke klik opgeslagen - geen voetnoot 'na N events samplen we'
Klik-events worden binnengehaald via een Kafka-compatibel topic en door onze ingest-service naar de analytics-store geschreven. Er is geen sampling-laag. Een link met 10 kliks en een link met 10 miljoen kliks hebben allebei elk event in dezelfde tabel - het schema verandert niet, er wordt geen aggregatie toegepast tijdens het binnenhalen. De bewaartermijn is 90 dagen op Free, 12 maanden op Pro en 24 maanden op Business. Na de bewaarperiode worden events definitief verwijderd; het aantal verwijderde events wordt gelogd. Het event-schema is openbaar - je ziet precies welke velden worden opgeslagen, zodat je je datamodel in je warehouse kunt plannen voordat je begint met exporteren. De vertraging tussen de klik en de beschikbaarheid in analytics is doorgaans minder dan 5 seconden; de consumer draait met auto-commit en logt vertragingsmetrieken, zodat je kunt zien of de pipeline achterloopt.
GA4 MP, Meta CAPI en Mixpanel server-side - gededupliceerd tegen de klik
Client-side pixels missen een aanzienlijk deel van de conversies, afhankelijk van adblocker-gebruik en iOS Safari ITP. Server-side doorsturing stuurt de conversie rechtstreeks vanuit de backend van Elido naar GA4 Measurement Protocol, Meta Conversions API of Mixpanel - geen client-side JS nodig. De deduplicatiesleutel is de click-ID: wanneer een conversie-event binnenkomt via een Stripe- of Shopify-webhook, koppelt Elido dit aan de oorspronkelijke klik en verspreidt het naar alle geconfigureerde server-side endpoints. De click-ID wordt op het moment van de klik als queryparameter meegegeven aan de bestemmings-URL; jouw checkoutflow moet deze doorgeven tot aan het conversie-event. Elk doorgestuurd event draagt de originele UTM-parameters van de klik mee, zodat attributie de hele funnel overleeft. Dit is nuttig om conversies terug te winnen die client-side pixels missen - het is geen vervanging voor een volledig CDP, maar het dicht het gangbare last-click-attributiegat.
Alleen-lezen analytics-DSN per workspace - sluit direct aan op Metabase, Hex of Grafana
Business-workspaces krijgen een alleen-lezen analytics-DSN per workspace, gescoopt op hun event-tabel. Wijs Metabase, Hex, Apache Superset, Grafana of elke compatibele SQL-/BI-client naar de DSN en schrijf rechtstreeks SQL tegen je klik-eventdata. De DSN is roteerbaar zonder de events-tabel te wijzigen; deze verbindt met een alleen-lezen gebruiker die alleen SELECT mag uitvoeren, geen INSERT of DROP. Het event-schema is stabiel en versioned; schemawijzigingen krijgen een migratiegids in de changelog voordat ze worden doorgevoerd. Voor teams die klik-events willen combineren met hun eigen productdata - 'welke links leverden gebruikers op die vervolgens activeerden?' - is het patroon om klik-events via een ingeplande export naar je eigen warehouse te kopiëren en daar te joinen. De analytics-DSN is voor teams van wie de BI-tool rechtstreeks via standaard SQL kan verbinden en die niet hoeven te joinen met externe tabellen.
Ingeplande exports naar S3, BigQuery en Snowflake
Ingeplande export draait op een instelbare frequentie (per uur, dagelijks) en verstuurt de klik-eventstroom - of een subset gefilterd op domein, campagne of link-tag - naar S3, BigQuery of Snowflake. De S3-export gebruikt standaard Parquet (JSON is ook beschikbaar); BigQuery en Snowflake gebruiken de native connectors met een schema dat Elido aanmaakt en actueel houdt. Incrementele exports worden gesleuteld op de event-timestamp; de eerste export is een volledige backfill tot aan je bewaartermijn; volgende exports voegen alleen nieuwe events toe. Als je vanaf een specifiek tijdstip opnieuw moet afspelen, is een eenmalige volledige export beschikbaar via een supportverzoek. Mislukte exports worden gelogd en opnieuw geprobeerd; er gaat een dead-letter-melding naar het workspace-e-mailadres als een batch langer dan 2 uur mislukt.
Real-time Kafka-consumer voor eventpipelines die niet kunnen wachten op batch-exports
Business-workspaces kunnen klik-events rechtstreeks consumeren uit een Kafka-compatibel topic als Kafka-consumergroep. Je krijgt een consumergroep-ID, een bootstrap-server en een clientcertificaat - standaard Kafka-consumerconfiguratie. Dit is de juiste weg voor real-time alerting (piekdetectie op een link, geo-anomaliesignalering), real-time dashboards die data binnen een fractie van een seconde nodig hebben, en pipelines waarvoor de frequentie van ingeplande exports te traag is. De firehose levert elk event minstens één keer af; jouw consumer is verantwoordelijk voor idempotentie bij herhaling. De bewaartermijn van het topic is 7 dagen; als je consumer meer dan 7 dagen achterloopt, gaan events verloren - richt monitoring in op consumer-vertraging. Dit is geen beginners-analyticsfunctie; het vereist Kafka-consumercode en operationele ervaring met consumergroepen. Als een ingeplande export naar BigQuery voldoet aan je behoefte, begin daar dan mee.
Stack waarmee je te maken krijgt
- Ruwe klik-events
- Directe SQL-toegang
- GA4 / Meta CAPI / Mixpanel
- S3 + BigQuery-export
- DSN per workspace
- Webhook-firehose
Wat je zult meten
- Sampling-percentage
- 0% - elke klik opgeslagen
- Vertraging bij event-ingest
- Minder dan 5 seconden
- Bewaartermijn
- Tot 24 maanden
Analytics-teams die hierop draaien
Namen zijn voorlopig plaatshouders - echte klantnamen komen hier zodra case studies zijn gepubliceerd.
“Met de alleen-lezen analytics-DSN konden we Metabase rechtstreeks aansluiten op klik-eventdata zonder een ETL te bouwen. We beantwoorden nu 'welke campagne dreef de MQL-naar-SQL-conversie?' vanuit een Metabase-dashboard, zonder extra infrastructuur.”
“Server-side Meta CAPI via Elido herstelde attributie op ongeveer 25% van de conversies die onze client-side pixel miste. De opzet kostte één sprint; de verbetering in attributienauwkeurigheid was direct merkbaar.”
“We consumeren de Kafka-firehose in onze eigen streamprocessor. Een eventvertraging van minder dan 5 seconden betekent dat onze real-time linkprestatie-dashboards de redactie tijdens live-evenementen niets wijsmaken.”
Elido analytics vs Bitly Analytics vs Heap
Bitly Analytics is toereikend voor klikaantallen en basale geo-data. Heap is een volwaardig product-analyticsplatform. Onderstaande vergelijking is eerlijk over wanneer welke optie het juiste gereedschap is.
| Mogelijkheid | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Sampling van klikdata | 0% - elk event opgeslagen | Samengevoegd; ruwe events niet toegankelijk | Afhankelijk van abonnement op de gratis tier |
| Directe SQL-toegang | Alleen-lezen analytics-DSN (Business) | Geen directe DB-toegang | Heap Data Lake (warehouse-export) |
| Ingeplande export naar BigQuery/Snowflake | Ja, Business+ | Alleen CSV-export | Ja - kernfunctie |
| Real-time Kafka-firehose | Ja, Business+ | Niet beschikbaar | Niet beschikbaar |
| Server-side conversie-doorsturing | GA4 MP, Meta CAPI, Mixpanel - gededupliceerd | Niet beschikbaar | Server-side event-ingest (productevents) |
| Tracking op gebruikersniveau | Nee - alleen op klikniveau, geen gebruikersidentiteit | Nee | Ja - kernfunctie |
| Funnel- + cohortretentie | Klikcohorten op Business | Nee | Volledige funnel + cohort - volwassen |
| Bewaartermijn events | Tot 24 maanden ruwe data | Samengevoegde tellers; ruwe data niet beschikbaar | Varieert per abonnement |
Vragen van analytics-teams
Wat is het exacte event-schema voor klik-events?
Het schema is openbaar op /docs/api-reference onder 'Click events'. Belangrijkste velden: click_id (UUID), link_id, workspace_id, occurred_at (UTC-timestamp), country_iso2, region, city, device_type (mobile/tablet/desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Nullable velden zijn nullable, geen lege strings. Schemawijzigingen worden aangekondigd in /changelog met een migratiegids.
Is er een handleiding voor de Kafka-consumer?
Ja - /docs/guides/kafka-firehose behandelt de bootstrap-server, opzet van de consumergroep, rotatie van clientcertificaten en voorbeeldcode voor consumers in Go en Python. Er is één topic per workspace; het aantal partities ligt vast op 12. Offset-reset is standaard 'earliest' bij de eerste keer dat een consumergroep zich aansluit. Als je hierop bouwt, reserveer dan tijd voor het monitoren van consumer-vertraging - dat is het faalscenario dat teams treft die dit niet inrichten.
Kan ik klik-events joinen met mijn eigen gebruikerstabel?
In je warehouse, ja. Het standaardpatroon is: exporteer klik-events via ingeplande export naar BigQuery of Snowflake, en join vervolgens op de UTM-parameters of een eigen user_id-parameter die je toevoegt aan je short-link-bestemmingen. Elido slaat geen gebruikersidentiteit op in klik-events - de click_id is een willekeurige UUID per klik, niet gekoppeld aan een gebruikersaccount.
Hoe werkt server-side conversie-deduplicatie?
Wanneer je een conversie-event POST't naar het conversie-endpoint van Elido, geef je de click_id mee die in het oorspronkelijke klik-antwoord is teruggegeven (deze wordt als queryparameter aan de bestemmings-URL meegegeven). Elido zoekt de klik op, controleert of deze nog niet is toegewezen, en verspreidt de conversie naar GA4 MP, Meta CAPI of Mixpanel met de UTM-context van de oorspronkelijke klik. Dubbele inzendingen met dezelfde click_id zijn idempotent - ze worden bevestigd, maar niet dubbel geteld.
Wat gebeurt er als mijn Kafka-consumer achterloopt?
Events blijven 7 dagen bewaard in het topic. Als de vastgelegde offset van je consumergroep meer dan 7 dagen achterloopt, gaan oudere events verloren voordat je consumer ze leest. Monitor consumer-vertraging; stel een waarschuwing in bij 6 uur vertraging als vroege indicator. Als je achterloopt op een niet-herstelbaar event, dekt de ingeplande export naar S3/BigQuery het gat - een goede back-up voor de firehose.
Geeft de analytics-DSN toegang tot data van andere workspaces?
Nee. De DSN is uitsluitend gescoopt op de event-tabel van jouw workspace, via een alleen-lezen gebruiker met row-level security. Je kunt geen events van andere workspaces zien. De DSN kan worden ingetrokken vanuit de workspace-instellingen; roteer deze op dezelfde cadans als API-keys.
Is er een minimale steekproefgrootte voordat klikcohorten betekenisvol zijn?
De analytics-store voert de cohortquery uit op welke datagrootte er ook is - er wordt geen minimum afgedwongen. Statistische betekenisvolheid is jouw eigen inschatting. Een cohort van 50 kliks geeft je een getal, maar dat is ruizig. We tonen ruwe aantallen en percentages; we passen geen Bayesiaanse smoothing of betrouwbaarheidsintervallen toe op cohortweergaven. Voor formele analyse exporteer je en draai je je model in je eigen warehouse.
Kan ik de ingeplande export filteren op een subset van links?
Ja - exportfilters ondersteunen: specifiek domein, specifieke campagne-ID, specifieke tag, of een datumbereik. Een gefilterde export blijft incrementeel; volgende runs voegen alleen nieuwe events toe die aan het filter voldoen. Als je een nieuwe filtervoorwaarde toevoegt aan een bestaande exportjob, moet je ofwel een nieuwe job aanmaken, ofwel een eenmalige volledige re-export doen om de geschiedenis van het nieuwe filter aan te vullen.
Leeslijst voor analisten
Uitsplitsing per link, conversie-attributie, cohortretentie.
Server-side doorsturing naar GA4, Meta CAPI, Mixpanel.
OpenAPI 3.1-specificatie, klik-event-schema, getypeerde SDK's in TS / Py / Go.
HMAC-ondertekende events, retrybeleid, Kafka-firehose voor hoog volume.
DSN-opzet, schema, laadpatronen voor BigQuery + Snowflake.
Niet zeker welke invalshoek past?
De meeste teams beginnen met één invalshoek en groeien naar alle vier. Ons salesteam neemt in 20 minuten je specifieke stack met je door.