連絡先と同意
持っているだけでなく、擁護できるリスト
誰でも1万件のメールアドレスを保有できます。重要な問い — 規制当局、プロバイダ、そしてあなた自身の良心が、それぞれ少しずつ違う言葉で問う問い — は、各アドレスがどこから来たのか、どのような根拠で送信できるのか、というものです。ClickSomoはそれを後から再構築すべきものではなく、保存された事実にします。
IDはメールアドレス
1つのプロジェクト内の1つのアドレスにつき1つの連絡先。これは希望ではなくデータベースで強制されます。アドレスは書き込まれるときに正規化され、読み込まれるときには決して正規化されません。読み込み時に正規化すると、制約は飾りになり、Anna@とanna@の両方が入ってしまいます。
電話番号は存在する場合にはE.164形式で保存されますが、電話番号は属性であって識別子ではありません。識別解決グラフも、マージプロトコルも、マージの監査ログもありません。ここに連絡先が届くのは、すべてインポート、フォーム、購読、あるいはお客様自身のコードなど、すでにアドレスを持つチャネルを通じてだからです。
名前は全体のまま保存されます
display_nameは入力されたとおりにそのまま保持され、部分に分割されることはありません。名前の分割はバグの温床です。"van der Berg"、"Kim Min-jun"、単一名、敬称、そしてアングロ式ではないあらゆる氏名の順序の慣習。誤った分割はマージタグに"Dear van,"として現れ、パーソナライゼーションをまったくしない場合よりひどい結果になります。
構造化された部分は、すでに分離された形で提供するソースについてのみ存在します。何も派生させません。また、本人が自分で入力した名前は、たまたま異なる内容を観測した後のCSVによって上書きされることはありません。最後の書き込み優先では、最も雑なインポートが勝ってしまうからです。
- 1識別情報正規化されたメールアドレス。プロジェクト内で一意です。
- 2名前全体のまま保存されます。
first_nameはレンダリング時に派生され、保存されることはありません。 - 3属性JSON形式で自由に設定できます。お客様のデータであり、
attrs.*として差し込めます。 - 4タグとリストタグは第一級の存在で、1つのストアに保存されます。リストは明示的なメンバーシップです。
- 5同意チャネルごとに1行で、適法な根拠とその証拠を記録します。
- 6イベントこの人物が行ったすべてのことの追記専用ログ。プロダクトが依拠するテーブルです。
- ×表示しないパスワードも、ハッシュも、セッションも、APIキーもありません。誰かを認証する列は、機能ではなくインシデントになります。
テナントとプロジェクトの両方にスコープ
同意台帳
不在は許可ではない
連絡先ごと・チャネルごとに1行。メール、SMS、手紙、プッシュのそれぞれに、状態、適法な根拠、ソース、証拠、タイムスタンプ、管轄区域を記録します。あるチャネルに根拠行を持たない連絡先には、そのチャネルで何も送信できません。「フラグが立っていない」のではなく、送信できないのです。
consent
本人が能動的に求めたもの。証拠が保存されたフォーム送信、ダブルオプトイン、本人が自分でチェックしたチェックボックス。これは最も強い根拠であり、フォームが生成できる唯一の根拠です。
legitimate_interest
CSVインポートで到達しうる最良のもの。スプレッドシートは誰かが何かに同意したことを記憶できないため、同意したと主張することは決して許されず、同じファイルを再アップロードしても格上げされません。
contract
双方が当事者である何かのために書き送るもの。サービスのリマインダー、更新のお知らせ、受け取れないと困るもの。
キャンペーンの送信前に、オーディエンスの根拠の内訳が表示されます。何人が自ら求めたか、何人が正当な利益のもとにリーチされるか、何人が契約によるか。警告バナーのどれよりも多くの誤った送信を止めてきた、たった一つの数字です。
なぜお客様にとって必要以上に厳格なのか:これは実のところお客様のためではありません。一括送信の評判は共有資源であり、不注意な1つのリストが、同じインフラから送信する全員の井戸を汚染します。テナントごとの苦情率とバウンス率は監視されており、しきい値を超えたアカウントは、プロバイダが全員に対して一斉に措置を取る前に、ここで制限されます。
リストのすべての行の背後には、誰かが「はい」と言った事実があります。
4つの入り口
リストに入るすべての経路は、お客様がご自身のデータに対して行う操作です
サービストークンの取り込み経路も、お客様の連絡先に密かに書き込む姉妹製品もありません。誰かをリストに入れたい場合、その4つのうちのいずれかがその人物をそこに置いたことになります。
CSVインポート
列ごとにマッピングされ、書き込み時に正規化され、MXチェックによって無効なドメインやタイプミスのドメインがハードバウンス前に検出され、お客様が明示的に設定した根拠とともに取り込まれます。インポートにはIDが付与され、作成されたすべての連絡先がそのIDを参照します。
ClickSomoのフォーム
他と同じドキュメントからレンダリングされ、バリデーション、ハニーポット、レート制限を備えます。フォーム送信は、consentを正当に生成できる唯一の経路です。本人がその場にいる唯一の経路だからです。
dash-bで構築したページ
ダッシュボードデザイナーがページを公開し、そのページ上のフォームがお客様自身の認証情報でここに送信します。同じバリデーション、同じ同意処理、維持すべき第2の統合はありません。
公開API
お客様自身のトークンでPOST /v1/contactsを呼び出します。アップサートセマンティクス、冪等キー対応。お客様のアプリはすでに誰がサインアップしたかを知っています。その事実からファネルまでの最短経路がこれです。
セグメントは述語であり、コンパイルされます
セグメントは、連絡先フィールド・属性・タグ・リスト所属・行動にわたる保存済みの述語ツリーで、SQLにコンパイルされ、件数とともにキャッシュされます。演算子は通常のもの — 等しい、等しくない、含まれる、含まれない、で始まる、で終わる、含む、設定済み、未設定 — で、and・or・not を必要な深さまで組み合わせられます。
使用前にプレビューしてください。エンドポイントは実際の連絡先を返すので、「実際に誰が含まれるのか」は送信して知るのではなく、見て答えられる質問です。
セグメントは二役を果たします:キャンペーンのオーディエンスとして、ファネル分岐の条件として、そしてそれ自体がトリガーとして — segment_enter は、誰かが対象になった瞬間に実行を開始します。
- 1タグ
tags contains "regular" - 2属性
attrs.total_orders >= 3— あなたのフィールド、あなたが付けた名前です。 - 3動作過去90日間に
order.paidイベントがありません。 - 4同意使用可能なメールの根拠。根拠のない連絡先は件数に含まれません。そもそも送信できないためです。
- iプレビュー412件の連絡先を表示しています。送信時に再度カウントされます。セグメントは質問であってスナップショットではないからです。
SQLにコンパイル件数はキャッシュ、回答はライブ
抑制と、その確認タイミング
抑制はプロジェクト単位かつグローバルです:ハードバウンス、苦情、配信停止、手動登録、ロールアドレス。これらは送信時に確認され、さらに送信サービス内部でも再度確認されます。
その2回目の確認が重要です。3日間の待機を含むファネルでは、3日間の間に配信停止できる窓があり、キュー投入時にしか抑制を確認しないシステムは、そのままメールを送ってしまいます。送信時の確認こそが、配信停止を尊重することと記録するだけことの違いです。
消去も同様に機能します:削除要求はここで連絡先とそのメッセージ履歴を削除し、コピーを保持しているすべての兄弟サービスに、ファミリーの他の部分が使うのと同じ内部経路を通じて届きます。依頼する場所は一つ、起こることは一つです。