1つのファネル、20のクライアント、20の評判を完全に分離

クライアントごとに1プロジェクト、境界はデータベースの役割

ここでのすべてはテナントとプロジェクトの組み合わせにスコープされます。連絡先、ファネル、クリエイティブ、キャンペーン、送信ID、レポート。このスコープは、クエリに誰かが忘れずに句を追加するのではなく、データベースの行レベルセキュリティによって強制されます。プロジェクトを指定し忘れたクエリは、最初のプロジェクトの行ではなく、何も見えません。

つまり、あるクライアントのリストが誤って別のクライアントのキャンペーンに漏れることはなく、レポートは1つのクライアントについてのものであり、構造的に2社にまたがることができないということです。

各クライアントは自分自身として送信する

送信IDはプロジェクトに属します。自社のドメイン、自社のDKIMキー、自社のメールボックスまたはプロバイダアカウント、自社の送信レート上限。あるクライアントの不運なキャンペーンが、別のクライアントの到達率を損なうことはありません。そもそも損なうべき共有物が何もないからです。

これにより、気まずい話し合いも早い段階で片付きます。クライアントは自らの送信、リスト、同意記録を所有します。退社する際（退社するクライアントも出てきます）、そのすべてを持って去り、説明に苦しむような人質状態を構築することはありません。

月次レポートの問題

代理店のレポート作成の苦痛の大半は、数値の作成ではありません。クライアントの追加の質問に耐える数値を作成すること、そして月初めに3時間スクリーンショットを撮らずにそれを作成することです。

ここで役立つ2つの要素があります。レポートはAPIルートなので、月次パックはスクリプトで組み立て、PDFとしてエクスポートでき、人とスプレッドシートに頼る必要がありません。また、数値はボットについて正直です。生データとフィルタ済みの両方がラベル付きで利用でき、クライアントが移行後に開封率が下がった理由を尋ねたとき、4文で弁明する代わりに1文で説明できます。

同じタイルがdash-bにも表示されます。キャンペーンのパフォーマンス、ファネルの離脱、リストの成長、ドメイン別の到達率。ライブボードを望むクライアントには、自らのアカウント、自らの認証情報で、あなたのキーをページに残さずに提供できます。