各売上が、その売上を生んだ訪問を見つける仕組み

01訪問者 ID

Cookie モードでは、スニペットが各ブラウザに ID を割り当て、ファーストパーティ Cookie _tally_vid に 1 年間保存します。チェックアウトがその ID を決済サービスに渡し、決済が届くと Tally がそのブラウザと、そのブラウザの訪問を見つけます。

DataFast の datafast_visitor_id Cookie を持って訪れた訪問者はその ID を引き継ぐので、DataFast 用に書いたチェックアウトのコードはそのまま動きます。同意優先モードでは訪問者が同意した時点で ID が生まれ、Cookie なしモードでは ID がないため、完了ページとメールアドレスの照合で紐づけます。

02決済の紐づけ方（確かなものから順に）

当てはまる方法はすべて試し、最も確かなものを採用します。まず確度、次にこの表での順番で判断します。保存済みの紐づけは、より確かなものにしか置き換わらないため、後から来た根拠で売上の紐づけが強まることはあっても、弱まることはありません。ID が有効なのは、サイトが実際に見た訪問者のものだけです。

紐づけは決済が届くたびにサーバーで実行され、通常は数秒で終わります。また、決済後の identify や遅れて読み込まれた完了ページなど、新しい根拠が見つかったときは、直近 30 日分の決済について再び実行されます。

03どの訪問に帰属するか

• 売上は、購入者のそれ以前の訪問のうち Direct 以外で来た最後の訪問に帰属し、そうした訪問がなければ最後の訪問に帰属します。初回訪問も記録されるため、両方を確認できます。
• メール内の Payment Link から支払った場合など、決済より前に訪問がない購入者は、決済後 15 分以内に始まった最初の訪問、つまり完了ページへの戻りに帰属します。
• 更新とアップグレードはサブスクリプションの初回決済と同じ帰属先に、返金とチャージバックは取り消す対象の決済と同じ帰属先になります。

04レシート

Sales の各売上を開くと、レシートが表示されます。初回訪問、売上が帰属する訪問、決済をそのブラウザに結びつけたもの（識別子とそれが見つかった場所）、そして決済で、決済サービスで照会できる ID が付いています。何も売上を紐づけなかった場合は、レシートにそう示されます。推測で埋めることはありません。

05カバー率と修正

カバー率は、売上のうち訪問者に紐づいたものの割合（金額ベース）です。返金とチャージバックは取り消す対象の売上に従うため、カバー率には含めません。

その下の Coverage and fixes では、紐づいていない売上を理由ごとに金額の大きい順にまとめ、それぞれに次の売上を紐づけるためのコードを示します。各修正については訪問のない売上で説明しています。

06決済サービス

• StripeCheckout Session、Payment Links、PaymentIntent、請求書。
• PaddlePaddle Billing の取引、返金、チャージバック。
• Lemon Squeezy注文とサブスクリプションの請求書。
• Polar注文、返金、敗れた異議申し立て。
• WooCommerce支払い済みの注文とその返金。
• Squarespaceストアの注文と返金。注文状況ページで紐づけます。
• Payments APIそのほかすべて。サーバーから送信します。

07紐づけられないもの