概要

KARTEで送信するイベントは、ページの再読み込みや通信の再送により、同じ内容が複数回計測されることがあります。
KARTEによって自動発生するイベント以外のコードを書いて発生させるイベントについては、transaction_idを指定することで、重複イベントの計測を防ぐことができます。

補足

KARTEによって自動発生するイベントを明示的に発生させるような場合にも、この方法で重複計測を防ぐことができます。

ここでは、重複したイベントが送信された場合の判定仕様、重複計測を防ぐ実装方法を説明します。

イベント送信経路

重複したイベントが送信された場合の判定の仕組みを説明する前に、コードを書いて発生させるイベントの送信パターンについて説明します。
コードを書いて発生させるイベントは、以下3つのいずれかの経路から送信されます。

イベント送信経路による重複判定の違い

transaction_idを指定して、イベント送信することでKARTE側でイベントの重複判定が行われます。
重複判定は「クライアント側」と「サーバー側」で行われており、どちらによる判定が行われるかは次の表で示すように「イベントの送信経路」で挙げた経路によって異なります。

イベントの送信経路クライアント側の重複判定サーバー側の重複判定
計測タグ(JS SDK)ありあり
App SDKなしあり
サーバーサイドAPIなしあり

イベントの重複計測を防ぐためのKARTE側の仕組み

KARTEでは、クライアント側とサーバー側の2段階で重複判定を行います。
計測タグ(JS SDK)から送信した場合は、クライアント側判定の後にサーバー側判定が行われます。
App SDK やサーバーサイドAPI から送信した場合は、サーバー側判定のみが行われます。

クライアント側

ブラウザに保存された情報をもとに重複判定を行います。
最初の送信から30分間は、イベント名が異なる場合であっても、同一のtransaction_idを持つイベントが計測タグ(JS SDK)経由で送信された場合にその送信が抑止されます。

ご注意ください
  • 同じブラウザでは、ページ遷移や再読み込み後も判定が継続します
  • 別ブラウザや別端末には判定情報は引き継がれません
  • ブラウザの保存データを削除すると、判定情報も失われます

サーバー側

サーバー側でも重複判定を行います。
サーバー側では、「同一ユーザー × 同一イベント名」単位で直近30件のtransaction_idを保持しています。
31件目以降のtransaction_idが送信されると、古いものから保持対象から外れます。

ご注意ください
  • クライアント側の重複判定とは異なり、時間による制限はありません

サーバー側の重複判定されるケースについて、以下に具体例を示します。

ケース1:保持上限を超えて31件目のtransaction_idを送信したとき

【前提】

  • 「user1 × eventA」単位でサーバー側が1~30のtransaction_idを保持している

日時送信するユーザー送信するイベント送信するtransaction_idイベントが計測されるか説明
9:00user1eventA1×1はすでに保持されているため重複排除される
9:30user1eventA31◯31は保持されていないので重複排除されない
9:50user1eventA1◯1は保持対象から外れているので重複排除されない

ケース2:異なるイベント名で同じtransaction_idを送信したとき

【前提】

  • 「user1 × eventA」単位でサーバー側が1~30のtransaction_idを保持している

  • 「user1 × eventB」単位の組み合わせはサーバー側で保持していない

日時送信するユーザー送信するイベント送信するtransaction_idイベントが計測されるか説明
9:00user1eventA1×1はすでに保持されているため重複排除される
9:10user1eventB1◯eventBの1については保持されていないので重複排除されない

ケース3:異なるユーザーが同じtransaction_idを送信したとき

【前提】

  • 「user1 × eventA」単位でサーバー側が1のtransaction_idを保持している

  • 「user2 × eventA」単位の組み合わせはサーバー側で保持していない

日時送信するユーザー送信するイベント送信するtransaction_idイベントが計測されるか説明
9:00user1eventA1×すでに保持されているため重複排除される
9:05user2eventA1◯異なるユーザーからの送信であるため重複排除されない

実装方法

transaction_id の実装を推奨するケースや注意点、イベントの送信方法ごとの実装方法について説明します。

実装を推奨するケース

transaction_id の実装は、次のようなイベントで検討してください。

  • 購入完了(buy): サンクスページの再読み込みによる購入数の二重計測を防ぎたい

  • 申込・資料請求完了: 完了画面の再表示によるコンバージョン数の重複を防ぎたい

  • 会員登録完了: 登録処理の再実行による二重計測を防ぎたい

補足

transaction_id はイベントの重複計測を防ぐための仕組みです。すべてのイベントに必須ではありません。重複計測が問題にならないイベントについての実装は不要です。

実装する上での注意点

transaction_idは、各イベントごとに一意な値を指定してください。

同じ値を複数のイベントに指定した場合、意図したタイミングでイベントが発生しなくなる可能性があります。

イベントの送信方法ごとの実装方法

イベントの送信方法ごとの実装手順について説明します。

計測タグ(JS SDK)からイベント送信するとき

計測タグからイベントを送信する場合は、krt('send') の第3引数に transaction_id を指定します。

krt('send', 'test', {
  transaction_id: 'ORDER-12345',
  revenue: 2000
});

App SDKからイベント送信するとき

App SDK(iOS/Android)では、transaction_id は通常のイベントフィールドとして送信され、サーバー側でのみ重複判定が行われます。イベント送信の実装方法は、利用するSDKのドキュメントをご確認ください。

サーバーサイドAPIからイベント送信するとき

サーバーサイドAPIからイベントを送信する場合は、サーバー側でのみ重複判定が行われます。transaction_id は、イベントの values に指定してください。

{
  "keys": {
    "user_id": "user_1"
  },
  "event": {
    "event_name": "test",
    "values": {
      "transaction_id": "ORDER-12345",
      "revenue": 2000
    }
  }
}

サーバーサイドAPIの設定方法は、次のドキュメントをご確認ください。