Eメールエキスパートシリーズ:ESP移行について

公開: 2021-08-18

Eメールマーケターにとっては非常に多くの取引ツールがあり、Eメールサービスプロバイダー(ESP)が業界で大きなトピックになることは明らかです。 どのESPがどのサービスを提供し、それらは配信可能性に影響を与えますか、どのESPが自分に適しているかをどのように決定しますか? これらの質問の後に、さらに難しい質問があります。メールマーケティングプログラムに損害を与えることなく、あるESPから別のESPに移行するにはどうすればよいですか。

次のEメールエキスパートシリーズのビデオでは、その質問に対する複雑な答えを探り、なぜ誰かがこの状況に陥るのか、ある状態から別の状態に移行する方法、そしてこれらのシナリオで期待できる(そして期待すべき)ことに触れます。 追加のボーナスとして、Iterableの主要な電子メール配信可能性および業界関係マネージャーであるSeth Charlesが、ホストとしてのAnthony Chiulli、技術専門家としてのLuke Martinez、および知っているパートナーシップのディレクターであるJulieCovalを含む250okの専門家のチームに加わりました。 ESPの関係とユースケースがどれほど複雑になる可能性があるか。

(主要なタイムスタンプを見つけて、このビデオを以下に転記しました。)

合計実行時間:14分

00:47 –電子メールサービスプロバイダー(ESP)の移行における一般的なリスクと課題
3:12 –IterableのSethCharlesが、移行の準備をしているマーケターにアドバイスを提供します
4:28 –新しいESPを評価する際の提案依頼書(RFP)プロセスの推奨事項
7:10 –マーケターがESPの切り替えを検討する良い理由と悪い理由
9:10 –移行の青写真を持ち、チームの責任を定義することの重要性
12:04 –マーケターが複数のESPを活用すべきまたは活用すべきでない理由


お気に入りのプラットフォームで聞いて購読します。


トランスクリプト

アンソニー・チウリ
やあみんな。 私の名前はアンソニー・チウリです。私はここインディアナポリスのエッジスタジオに住んでいて、素晴らしいキャストが加わっています。 今日はESP移行の非常にクールなトピックについて話します。マーケターがそれらのいずれかを実行している場合は、いくつかのヒントとコツを理解する必要があります。 また、この業界にいる私たち全員から、避けて軽減すべきことについていくつかのことを学びました。 ですから、私の右側にはルーク・マルティネス、左側にはジュリーが加わっています。今日は、ゲストとしてIterableのSethCharlesとしてリモートでダイヤルインしています。 みなさん、今日はご参加いただきありがとうございました。さっそく始めましょう。

ESPの移行は、ESPの移行を経験したマーケティング担当者にとって、見過ごされ、誤解されることが多いものだと思います。 通常、その経験については戦争の話や目が回るようなものがありますが、当然そうですよね? それはあなたのマーケティング技術スタック全体を根こそぎにし、それをあるプラットフォームから次のプラットフォームに移すことであり、それは骨の折れる仕事です。 ルーク、あなたの経験から、一般的に、あるプラットフォームから別のプラットフォームへの移行に伴う懸念やリスクにはどのようなものがありますか?

ルーク・マルティネス
ええ、たくさんあります。 つまり、最初に頭に浮かぶいくつかのことです。私たちは皆、移行を行うさまざまな戦いを戦ってきたと確信していますが、タイミングは重要であり、いつ実行するかを選択します。 多くの人が最も多くのメールを送信している11月と12月にはそれをしないでください。 また、以前のESPと新しいESPで少しバッファーを確保するという観点からタイミングを調整します。 したがって、厳しい締め切り日はなく、その日に完全に移行されることを期待してください。 いくつかのオーバーラップが必要です。 残念ながら、短期間で2枚の請求書を支払うことになるでしょうが、思ったとおりに進まないので、それだけの価値はあります。 ダイヤルバックする必要があり、次にスピードアップする必要があり、ある程度の冗長性が必要になるため、以前の関係の終了と新しい関係の開始のタイミングを合わせることが非常に重要です。 明らかに、ダウンタイムはオプションではなく、ウォームアップもまた、一種の脆弱なものです。 いつでも好きなだけメールを送ることができるとは限りません。 したがって、ダウンタイムを回避するには、オーバーラップをいくつか持って、適切なタイミングをとる必要があります。

交流
ジュリー、ESPの移行で頭に浮かぶ他の課題は何ですか?

ジュリー・コヴァル
ええ、ESPの移行を検討しているときでも、組織にとってどのESPが最も理にかなっているのかを判断するために、すでに多くの調査を行っていると思います。 しかし、その一環として、完全な統合計画を作成し、実際にどれだけの時間がかかるかを考えるには、さらに多くの努力が必要になります。 私はルークがそのESPオーバーラップタイムを持っていると述べたことを知っています。 さて、あなたは本当にあなたが移行するのにどれくらいの時間がかかるかを理解していることを確認する必要があります、わかりました、まあ、私は以前のESPがどれくらい必要になるのですか? また、元の計画に加えて、おそらく修復計画が必要であることを理解してください。 予期せぬ事態が発生し、予期しないことが起こった場合に備えて、どうすれば回避できるかを確認したいのですが。

交流
だからセス、私はIterableでのあなたの視点と配信可能性の監督に本当に興味があります。 毎週新しい顧客を獲得し、これらのウォームアップ、移行、エスカレーションの多くに関与していると確信しています。 あなたの経験から、あなたが見ているあなたの席からの挑戦のいくつかは何ですか?

セス・チャールズ
ええ、つまり、私たちがよく扱っていることは、顧客が私たちのところに来たときにどのように見えるかを調査しているときに、私たちが常にそれらの間に同等性があることを確認したいと思っていることを確認することです機能セットとセグメンテーションのロジックと機能。 ダウンタイムが発生したり、セグメンテーションロジックをつなぎ合わせたりする必要がないことを確認するために、以前と同じかそれを超えていることを確認します。 そして、私のキャリアを通して私がたくさん扱ってきたもう1つの大きな問題は、送信者が抑制テーブルなどのデータベースの重要な側面を転送できるようにすることです。 そのため、新しいプラットフォームにアクセスすることはなく、突然、新しいインフラストラクチャから送信すると明らかに多くの問題が発生するため、履歴抑制データが不足します。 つまり、これらは、少なくとも最初は、私たちが焦点を当てている2つの主要な柱の一種です。

交流
ええ、私は同意します。 その上で、これは次の質問につながる優れた回答だと思います。移行が行われる前に、少しでもバックアップをとるのは、多くの顧客やマーケターがどのESPに適しているかを評価するRFPプロセスです。私の事業。 マーケターがRFPやショッピングに入札するとき、またはRFPやショッピングESPに入札するときに、何を検討することをお勧めしますか。これらはフォローされていませんか? ショッピングRFPプロセスに関する推奨事項を教えてください。

SC
ええ、間違いなく。 そして、私たちはこれを1トン通過しますよね? ですから、私たちが顧客とよく話し合う一番のことは、顧客が短期的なことを考えていないことを確認することです。 顧客が契約の終了などの立場にあり、ESPプラットフォームを急いで移動することを検討する必要がある場合は、長期的な目標を念頭に置くことが常に重要です。 長い間ビジネスに影響を与える可能性のあるこれらすべての変更をこれほど重要なものにしたくないからです。 あなたはそれをただ短期的な目標に基づいて作りたくありません。 あなたは、ある種の前進を拡大できるように、自分自身を確実に、ある種の位置に置きたいと思っています。 もう1つの大きな問題は、レポートの側面です。そのため、彼らが取得できると期待するレポートと、彼らが自分たちの側で決定を下し、適切に一致させ、そして彼らに教育するのを助けるために依存するものを確認します。彼らが持っているかもしれないカスタムレポート機能のいくつかは、彼らが時間とともにさらに良くなることを可能にするかもしれません、それは明らかにその長期計画の一部です。 そして、データフロー自体の観点からは常に重要になります。 したがって、Webhookが適切に配置されていることを確認し、統合が行われていることを確認してください。そうすることで、サブスクライバーデータベースなどを、最小限の成長の苦痛で更新できるようになります。

交流
ええ、それは素晴らしい反応だと思います。ESPの移行は、ブランドや企業が数年以内に何度もやりたいことではないため、今日ではなく将来の正しいサイズについて話すときは大好きです。 私はそれが常に一種であると思います、あなたの現在のニーズとウォンツを超えて購入し、あなたが成長し、あなたのビジネスを最適化し続けることを可能にするプロバイダーを楽観的に選択してください、そうすればあなたは特徴や機能の欠如のために別の移行に直面しません近い将来に。

LM
うん、うん。

交流
ルーク、ブランドがプラットフォームの切り替えを検討する必要がある正当な理由と無効な理由のいくつかについて話してください。

LM
ええ、切り替える理由はたくさんありますが、残念ながら一般的な悪い理由もたくさんあります。 そして、悪い理由の例は、魔法のIPアドレスまたはより良い配信可能性であると思います。 私がESPスペースにいたとき、私たちはこれをたくさん手に入れていました。 私たちの競合他社—そして私たちもそれについて有罪でした。私たちは配信可能性で最高であると言えます。真実は、送信者が配信可能性に関して彼らの運命を決定するということです。 それはあなたの婚約です。 それはあなたの不満です。 それはあなたのコンテンツです。 ESPには、電子メールの送信で優れた仕事をするだけの魔法のIPアドレスはありません。 ですから、私は常に、ESPを切り替えることでオープンレートが向上するというこの考えを押し戻そうとしています。 もしそうなら、それはあなたがどこかで良くも悪くもしている可能性が高いからです。 競争力のある価格設定、それがおそらく正当な理由だと思います。 明らかに、誰もが予算を持っています。 最近、実際のメール送信はコモディティ化されているので、価格設定の理由になることもあります。 しかし、切り替える最大の理由はサービスレベルにあると思います。 あなたはあなたのパートナーになるこれらの人々を信頼し、あなたがあなたのビジネスの本当に重要な部分、あなたにとって重要なチャネルを管理するのを助けますか? それで、彼らのサービスレベルは何ですか? 機能性、セスがリストアップしたもののいくつかを知っているので、オーディエンスにターゲティングさせたいセグメンテーションを実行できますか? キャンペーンビルダーは私がやりたいことをしますか? 自動化ワークフローはありますか? 多分あなたもそれらを必要としないでしょう。 それで、利用できるかもしれないいくつかの鐘と笛、あなたは実際にそれらを使うつもりですか? だから私にとって、正当な理由は、機能性、ある程度、価格、サービスレベル、あなたとESPの間の関係レベルのようなものです。 悪い理由は、「オープンレートが低いので去る」ということです。 それはあなたのESPではありません。 オープンレートが低いということは、魂の検索を行い、サービスチームと協力し、250okなどのツールを活用して、ESPの障害がほとんどないため、原因を特定するのに役立てる必要があるということです。

交流
ほとんどは決してない。 同意します。 ジュリー、考え方と準備だけはどうですか? したがって、RFPプロセスを実行し、切り替えを行う正当な理由を選択すると、移行の計画と準備を行う準備が整います。 その側面に関する推奨事項は何ですか?

JC
ええ、あなたが言ったように、あなたはすでに多くのプロセスを経ていると思います。 どのESPが自分にとって最も理にかなっているのかを判断したため、おそらく興奮しているでしょうが、プロセスの中で最も重要なステップの1つにいると思います。つまり、自分が持っていることを確認する必要があるという事実です。明確な移行計画。 その理由は、新しいESPに移行するときに、村が必要になるからです。 これは、マーケティングチームだけでなく、ITチーム、製品チーム、実際にはESPに触れたり、ブランドに触れたりするすべての人からの部門横断的な取り組みになります。 したがって、全員が自分の役割と実行しているタスクだけでなく、タイムラインと予想されるマイルストーンも一致していることを確認する必要があります。 あなたは物事を成し遂げたいと思う期間を設定する必要があります。そうでなければ、あなたはただ流れに沿って進み、誰が何が起こるかを知っているからです。 その一環として、少し前に触れたのは、その修復計画を確実に実施することです。 つまり、最初の移行計画を精査して、全員が同じページに表示されるようにしたいと思いますが、前述したように、何らかの予期しない事態が発生する可能性があります。 何かが予期されていない場合に備えて、別の方向に進むことができることを確認する必要があります。 あなたが望んでいたことが時間通りに起こらなかったので、そのような計画Bがあることを確認する必要があります。私が知っておくべき重要だと思う他の2つの部分は、私からどのデータを転送できるかです。古いESPから新しいESPへ。必要なデータを取得するだけでなく、簡単に転送できない特定のデータがある場合は、それをキャプチャして維持する方法があります。 、そのデータを使用して、企業として前進できるようにします。 そして最後に、2、3回前に言ったことですが、これらのESPの両方をオーバーラップさせる時間を確保することです。これは、非常に大きなことだと思います。 数か月間少し余分に支払う必要があるのは残念ですが、以前のESPをそのままにして、メッセージを送信し続けることができ、必要なメッセージを送信できないようにすることが非常に重要です。新しいESPから。

交流
ええ、移行を成功させるには、私が「青写真」と呼んでいる準備と計画の重要性が最も重要だと思います。 そして、それは大規模な事業であり、あなたが言ったように、多くの部門が関与しており、確かに、その移行、その青写真を監督する強力なPMを持ち、あなたが述べたように、すべての人を軌道に乗せるための明確なタイムラインとステップとステータスを持っています重要です。 ルークとセス、私はあなたの意見を聞きたいと思いました。ルーク、あなたから始めましょう。多くの人が理解しているとは思わないが、多くの送信者は実際にビジネス全体で複数の送信プラットフォームまたはESPを使用しているという考えについてです。 多分それは異なるメールストリーム、または異なる部門のためです。 これは一般的な傾向ですか?おそらく複数のESPを使用することを検討する理由は何ですか?

LM
ええ、それは私が取った最後の質問に似ています。 複数のESPを行うには、良い理由と悪い理由があると思います。 正当な理由から始めます。 トランザクションメールストリームがあり、多かれ少なかれパイプとして動作する堅実な電子メールサービスプロバイダーがあり、それらを介してメッセージをトリガーしている場合。 マーケティングの自動化や美しいデザインテンプレートなどではありません。 それが彼らの操舵室、トランザクション電子メールである特定のESPがあります。 堅牢なAPIを備えています。 彼らはあなたが必要なだけ速くまたは遅くなどに電子メールを送ることができます、そしてあなたは自動化とドリップキャンペーンとこれらすべてのものを必要とする他のよりマーケティングと種類の育成に焦点を合わせたものを持っているかもしれません。 そして、あなたは彼らのテンプレートエディタを使いたいのです。 これらすべてを本当にうまくやっている人はほとんどいません。トランザクションが本当に得意な人もいれば、マーケティングがあまり得意でない人もいれば、その逆もあるという正当な理由があると思います。したがって、2つのESPを使用する正当な理由があります。 もう1つは、停止が発生した場合、最近のこれらのESPのほとんどに4〜9の稼働時間があり、非常に信頼性が高いと思います。 ただし、誰もが停止しています。あなたが大規模な送信者であり、1日中常にメールを送信していて、ESPがダウンした場合は、スイッチを切り替えてどこかに移動できるようにする必要があります。そうしないと。 その場合は、暖かくする必要があります。 どこか別の場所で新しいアカウントを圧縮して、初日に1,000万通のメッセージを送信することはできません。 しかし、常にそれぞれを少しずつ送信している場合は、ドメインに精通しているホットIPがいくつかあり、そのインフラストラクチャをしばらく使用しています。 切り替える必要がある場合は、それを行うことができます。 また、2つを使用していない場合、つまり、トピック全体がESPの切り替えです。 難しいので、用意しておいてください。必要に応じて切り替えることができます。

交流
セス、その質問に追加するものはありますか?

SC
ええ、つまり、ルークは間違いなくそれらの多くをヒットしたので、特定のESPが何かに長けていて、それらが専門とすることを行うためにさまざまなパイプを利用したい場合、それは非常に理にかなっています。 そして、完全に移管することが決定されたとしても、ジュリーが何度も言及したように、ウォームアップが完全に行われることはめったにないため、賭けを少しヘッジすることは必ずしも悪い考えではありません。初めて。 したがって、ウォームアップの一部として意図しないセグメントが含まれていて、それが実際に数日または数週間も後退する場合は、デフォルトで元に戻すことができるセーフティネットを用意することが常に重要です。何かが起こるイベント。 そして、ルークが明らかに述べたように、それはすでに暖かいので、あなたはそのインフラストラクチャを再び利用することができます。 送信するインフラストラクチャはすでに確立されており、フィルタリング会社やメールボックスプロバイダーが確実に探しているものです。

交流
ええ、私は同意します。 これは貴重な情報だと思います。 そして、セス、リモートでダイヤルしてくれてありがとう。 聴衆に感謝したいと思います。ESPの移行は気が遠くなるようなものだと思いますが、適切な準備とリソースがあり、RFPプロセス中、および移行前と移行後に適切な質問をするための情報があれば、それは実際に成功したプロジェクトになる可能性があります。 みなさん、見てくれてありがとう。