Click data you can actually query.
アトリビューション、離脱率、リフト値を測定。サンプリングや集計遅延なしで、全クリックを ClickHouse に保存。
- No click sampling at any tier — every event stored
- Per-workspace ClickHouse DSN, read-only, rotatable
- Scheduled S3 + BigQuery export (Parquet by default)
- Raw click events via webhook firehose / Kafka consumer
How click data lands
Click → Redpanda → ClickHouse, with no aggregation in the middle.
Most shorteners give you a counter. We give you a row per click, ingested in under five seconds, queryable from your own SQL client. The pipeline is one binary writing to one Kafka topic that one consumer drains into ClickHouse — no aggregation service, no daily summaries, no ‘sampled after 10K’ footnote.
- Step 1
Click
elido.me/x → 302Edge POP returns the destination + emits an event to Redpanda.
- Step 2
Redpanda
topic: clicks.<workspace>12 partitions, at-least-once delivery, 7-day topic retention.
- Step 3
ClickHouse
<5s p99 ingest lagclick-ingester 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.
Per-workspace ClickHouse DSN
A read-only DSN you can paste straight into Metabase.
Business workspaces get a per-workspace, read-only ClickHouse DSN scoped to their event table via row-level security. Plug it into Metabase, Hex, Apache Superset, Grafana, or any ClickHouse-compatible client. The DSN is rotatable from workspace settings without changing the underlying table.
- Stable schemaVersioned in /docs/api-reference; migration guides in /changelog
- Row-level securityDSN scoped to your workspace's event rows only
- BI-tool compatibleMetabase, Hex, Superset, Grafana, Looker — anything that speaks ClickHouse
- Sub-second queries1B-row tables under 1s for typical group-by-country / hour aggregations
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 |
Geography that survives the export
Country-level density on every click — not a hashed bucket.
Every click event includes ISO 3166-1 alpha-2 country, region, and city, resolved from MaxMind GeoIP at edge time. The IP itself is truncated to /24 (IPv4) or /48 (IPv6) before storage, so geo persists but PII does not. Below is the same data in the UI that lands in your warehouse — no aggregation tier in between.
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
Hourly Parquet to S3, then a native transfer into your warehouse.
The scheduled export pushes click events as Parquet to your S3 bucket on an hourly or daily cadence; native BigQuery Transfer or Snowflake external table loads it from there. The first run is a full backfill to your retention window; subsequent runs append only new events keyed on the event timestamp. Failures retry; a dead-letter notification fires if a batch can’t land within 2 hours.
- Parquet (default) or JSON; one object per hour-bucket
- Filter export by domain, campaign, or link tag
- Native BigQuery Transfer + Snowflake external table
- Dead-letter alert on >2h batch failure
- Kafka firehose for sub-second delivery (Business)
What you can do
- No click sampling at any tier — every event stored
- Per-workspace ClickHouse DSN, read-only, rotatable
- Scheduled S3 + BigQuery export (Parquet by default)
- Raw click events via webhook firehose / Kafka consumer
- Sub-second query latency on 1B+ row tables
- Server-side click attribution with click-ID dedupe
Elidoのデータモデルにおける「アナリティクス優先」の意味
ほとんどの短縮URLアナリティクスは集計された合計値です。以下の機能は、サマリーではなく生のリックストリームがプライマリアーティファクトになると何が変わるかを説明します。
すべてのクリックを保存 — 「Nイベント後にサンプリング」という注釈はありません
クリックイベントはRedpandaのKafkaトピック経由で取り込まれ、click-ingesterサービスによってClickHouseに書き込まれます。サンプリングレイヤーは存在しません。10クリックのリンクも1000万クリックのリンクも、すべてのイベントが同じテーブルに保存されます。取り込み時にスキーマが変更されたり、集計が適用されたりすることはありません。保持期間はFreeプランで90日、Proで12ヶ月、Businessで24ヶ月です。保持期間終了後、イベントは物理削除され、削除されたイベント数はログに記録されます。ClickHouseのスキーマは公開されており、どのフィールドが保存されているかを正確に確認できるため、エクスポートを開始する前にウェアハウスでのデータモデルを計画できます。クリックからClickHouseで利用可能になるまでのイベント遅延は通常5秒未満です。Redpandaコンシューマーはオートコミットで動作し、パイプラインの遅れを確認できるように遅延メトリクスをログに記録します。
GA4 MP、Meta CAPI、Mixpanelのサーバーサイド連携 — クリックとの重複排除
クライアントサイドのピクセルは、広告ブロッカーの普及やiOS SafariのITPによって、かなりの割合のコンバージョンを見逃します。サーバーサイドフォワーディングは、Elidoのバックエンドから直接GA4 Measurement Protocol、Meta CAPI、またはMixpanelにコンバージョンを送信します。クライアントサイドのJSは不要です。重複排除キーはクリックIDです。StripeやShopifyのウェブフック経由でコンバージョンイベントが到着すると、Elidoはそれを元のクリックと照合し、設定されたすべてのサーバーサイドエンドポイントに配信します。クリックIDはクリック時にクエリパラメータとして遷移先URLに渡されます。チェックアウトフローでコンバージョンイベントまでこれを保持する必要があります。転送される各イベントにはクリック時の元のUTMパラメータが含まれるため、ファネル全体で属性が維持されます。これはクライアントサイドのピクセルが見逃すコンバージョンを回収するのに役立ちます。フル機能のCDPの代わりではありませんが、一般的なラストクリック属性のギャップを埋めることができます。
ワークスペースごとの読み取り専用ClickHouse DSN — Metabase、Hex、Grafanaに直接接続
Businessワークスペースには、独自のイベントテーブルにスコープされたワークスペースごとの読み取り専用ClickHouse DSNが提供されます。Metabase、Hex、Apache Superset、Grafana、またはClickHouse互換のクライアントをDSNに向け、クリックイベントデータに対して直接SQLを記述できます。DSNはイベントテーブルを変更することなくローテーション可能です。SELECTのみが可能で、INSERTやDROPはできない読み取り専用ユーザーに接続します。ClickHouseのスキーマは安定しており、バージョン管理されています。スキーマの変更は、実施前にチェンジログでマイグレーションガイドとして案内されます。クリックイベントを自社のプロダクトデータと結合したいチーム（「どのリンクがアクティブ化したユーザーを誘導したか？」など）向けのパターンは、スケジュールされたエクスポートを介してクリックイベントを自社のウェアハウスにコピーし、そこで結合することです。ClickHouse DSNは、BIツールがClickHouseに直接接続でき、外部テーブルとの結合が不要なチーム向けです。
S3、BigQuery、Snowflakeへのスケジュールエクスポート
スケジュールエクスポートは設定可能な頻度（1時間ごと、毎日）で実行され、クリックイベントストリーム（またはドメイン、キャンペーン、リンクタグでフィルタリングされたサブセット）をS3、BigQuery、またはSnowflakeにプッシュします。S3エクスポートはデフォルトでParquetを使用します（JSONも利用可能）。BigQueryとSnowflakeは、Elidoが作成し最新の状態に保つスキーマとともにネイティブコネクタを使用します。増分エクスポートはイベントのタイムスタンプをキーにします。最初のエクスポートは保持期間までのフルバックフィルであり、その後のエクスポートは新しいイベントのみを追加します。特定のタイムスタンプからリプレイする必要がある場合は、サポートリクエストを介して単発のフルエクスポートが利用可能です。エクスポートの失敗はログに記録され、再試行されます。バッチが2時間以上失敗し続けると、ワークスペースのメールアドレスにデッドレター通知が送信されます。
バッチエクスポートを待てないイベントパイプライン向け。リアルタイムKafkaコンシューマー
Businessワークスペースは、KafkaコンシューマーグループとしてRedpandaトピックから直接クリックイベントを購読できます。コンシューマーグループID、ブートストラップサーバー、クライアント証明書といった標準的なKafkaコンシューマー設定が提供されます。これは、リアルタイムのアラート（リンクのスパイク検出、ジオアノマリのフラグ立て）、サブ秒のデータを必要とするリアルタイムダッシュボード、およびスケジュールされたエクスポートの頻度では遅すぎるパイプラインに適したパスです。ファイアホースはすべてのイベントを「少なくとも1回（at-least-once）」配信します。リプレイ時のべき等性はコンシューマー側の責任となります。トピックの保持期間は7日間です。コンシューマーが7日以上遅れると、イベントが失われます。コンシューマーの遅延を監視するように設定してください。これは初心者向けのアナリティクス機能ではなく、Kafkaコンシューマーコードとコンシューマーグループの運用経験が必要です。BigQueryへのスケジュールエクスポートで十分な場合は、そこから始めてください。
Stack you’ll touch
- 生のクリックイベント
- ClickHouse 直接アクセス
- GA4 / Meta CAPI / Mixpanel
- S3 + BigQuery エクスポート
- ワークスペース別 DSN
- Webhook ファイアホース
測定対象
- サンプリング率
- 0% — 全クリックを保存
- イベント取り込み遅延
- 5秒以内
- 保持期間
- 最大24ヶ月
この機能を活用しているアナリティクスチーム
名前は現在はプレースホルダーです。ケーススタディが公開されるにつれて、実際の顧客名に更新されます。
“ClickHouse DSNのおかげで、ETLを構築することなくMetabaseをクリックイベントデータに直接接続できました。今では、追加のインフラなしでMetabaseダッシュボードから『どのキャンペーンがMQLからSQLへの転換を促したか』に答えることができます。”
“Elido経由のサーバーサイドMeta CAPIにより、クライアントサイドのピクセルが見逃していたコンバージョンの約25%の属性を回収できました。セットアップは1スプリントで完了し、属性の精度向上は即座に現れました。”
“Kafkaファイアホースを独自のストリームプロセッサに取り込んでいます。イベント遅延が5秒未満であることは、リアルタイムのリンクパフォーマンスダッシュボードがライブイベント中に編集チームに対して嘘をついていないことを意味します。”
Elidoアナリティクス vs Bitly Analytics vs Heap
Bitly Analyticsはクリック数や基本的な地理データの把握には十分です。Heapは本格的なプロダクトアナリティクスプラットフォームです。以下の比較は、それぞれのオプションがどのような場合に適したツールであるかを正直に示しています。
| Capability | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| クリックデータのサンプリング | 0% — すべてのイベントを保存 | 集計済み。生のイベントにはアクセス不可 | 無料プランではプランに依存 |
| SQL直接アクセス | 読み取り専用ClickHouse DSN (Business) | データベースへの直接アクセス不可 | Heap Data Lake (ウェアハウスエクスポート) |
| BigQuery/Snowflakeへのスケジュールエクスポート | 可能 (Business以上) | CSVエクスポートのみ | 可能 — コア機能 |
| リアルタイムKafkaファイアホース | 可能 (Business以上) | 利用不可 | 利用不可 |
| サーバーサイドコンバージョン転送 | GA4 MP, Meta CAPI, Mixpanel — 重複排除済み | 利用不可 | サーバーサイドイベント取り込み (プロダクトイベント) |
| ユーザーレベルのトラッキング | なし — クリックレベルのみ、ユーザーIDなし | なし | あり — コア機能 |
| ファネル + コホート維持率 | Businessプランでのクリックコホート | なし | フルファネル + コホート — 成熟した機能 |
| イベント保持期間 | 最大24ヶ月の生データ | 集計カウンター。生データは利用不可 | プランにより異なる |
アナリティクスチームからの質問
クリックイベントの正確なClickHouseスキーマを教えてください。
スキーマは/docs/api-referenceの「Click events」セクションで公開されています。主なフィールド：click_id (UUID), link_id, workspace_id, occurred_at (UTCタイムスタンプ), country_iso2, region, city, device_type (mobile/tablet/desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content。Nullableフィールドは空文字列ではなくNullになります。スキーマの変更は/changelogでマイグレーションガイドと共に告知されます。
Kafkaコンシューマーのガイドはありますか？
はい。/docs/guides/kafka-firehoseで、ブートストラップサーバー、コンシューマーグループの設定、クライアント証明書のローテーション、およびGoとPythonのサンプルコンシューマーコードを解説しています。トピックはワークスペースごとに1つで、パーティション数は12に固定されています。オフセットリセットは、最初のコンシューマーグループ参加時はデフォルトでearliestになります。これをベースに構築する場合は、コンシューマー遅延の監視に時間を割いてください。これは設定を怠ったチームが直面しやすい失敗モードです。
クリックイベントを自社のユーザーテーブルと結合できますか？
はい、データウェアハウス内で可能です。標準的なパターンは、スケジュールエクスポート経由でクリックイベントをBigQueryまたはSnowflakeにエクスポートし、UTMパラメータまたは短縮URLの遷移先に付与したカスタムのuser_idパラメータをキーにして結合することです。Elidoはクリックイベントにユーザー情報を保存しません。click_idはクリックごとにランダムに生成されるUUIDであり、ユーザーアカウントには紐付いていません。
サーバーサイドコンバージョンの重複排除はどのように機能しますか？
ElidoのコンバージョンエンドポイントにコンバージョンイベントをPOSTする際、元のクリックレスポンスで返されたclick_id（遷移先URLにクエリパラメータとして渡されるもの）を含めます。Elidoはそのクリックをルックアップし、既に属性が付与されていないか確認した上で、元のクリックのUTMコンテキストと共にGA4 MP、Meta CAPI、またはMixpanelに配信します。同じclick_idでの重複送信はべき等に処理されます。受信はされますが、二重にカウントされることはありません。
Kafkaコンシューマーが遅延した場合はどうなりますか？
イベントはトピック内に7日間保持されます。コンシューマーグループのコミット済みオフセットが7日以上遅れると、コンシューマーが読み取る前に古いイベントが消失します。コンシューマーの遅延を監視し、早期警告として6時間の遅延でアラートを設定してください。回復不可能なイベントで遅れが生じた場合は、S3/BigQueryへのスケジュールエクスポートがギャップをカバーします。ファイアホースの優れたバックアップとなります。
ClickHouse DSNは他のワークスペースのデータにアクセスできますか？
いいえ。DSNは行レベルセキュリティ（RLS）が適用された読み取り専用ClickHouseユーザーを介して、ご自身のワークスペースのイベントテーブルのみにスコープされています。他のワークスペースのイベントを見ることはできません。DSNはワークスペースの設定からいつでも無効化できます。APIキーと同じ頻度でローテーションすることをお勧めします。
クリックコホートが意味を持つための最小サンプルサイズはありますか？
ClickHouseは存在するデータサイズでコホートクエリを実行します。最小サイズは強制されません。統計的な有意性はご自身の判断によります。50クリックのコホートでも数値は出ますが、ノイズが多くなります。Elidoでは生のカウントとパーセンテージを表示します。コホートビューにベイズ平滑化や信頼区間は適用しません。正式な分析には、データをエクスポートしてウェアハウスでモデルを実行してください。
スケジュールエクスポートを特定のリンクのサブセットにフィルタリングできますか？
はい。エクスポートフィルターは、特定のドメイン、特定のキャンペーンID、特定のタグ、または日付範囲をサポートしています。フィルタリングされたエクスポートも増分で行われます。その後の実行では、フィルター条件に一致する新しいイベントのみが追加されます。既存のエクスポートジョブに新しいフィルター条件を追加した場合、新しいジョブを作成するか、新しいフィルターの履歴を埋めるために1回限りのフル再エクスポートを行う必要があります。
Analyst’s reading list
Per-link breakdown, conversion attribution, cohort retention.
Server-side forwarding to GA4, Meta CAPI, Mixpanel.
OpenAPI 3.1 spec, click event schema, typed SDKs in TS / Py / Go.
HMAC-signed events, retry policy, Kafka firehose for high volume.
DSN setup, schema, BigQuery + Snowflake load patterns.
どの活用法が最適か迷われていますか？
多くのチームが1つのユースケースから始め、最終的に4つすべてを導入しています。弊社の営業チームが、20分で貴社の具体的なスタックに合わせたご提案をいたします。