mailinapp
Documentation menu

ESPを使ったエクスポート&送信

MailInAppは単独でも送信できます — 自分のドメインからのネイティブ送信、または自分のSMTPリレー経由のいずれかです — そのため、このワークフローは完全に任意です。すでにリストやオートメーション、送信者レピュテーションを構築済みのESPを運用している場合は、そこから離れる必要はありません。メールのデザインとコンパイルはここで行い、配信は普段から信頼しているESPに任せましょう。

ワークフロー

  1. スタジオでデザインを仕上げます。
  2. コンパイル済みのHTMLをエクスポートします。この1つのファイルには、キネティック・静的・Outlookという3つのフォールバックティアすべてと、ホスティングされたインタラクションエンドポイントおよびライブビューへのリンクが含まれています。
  3. 自分のESPで、カスタムHTML / コード貼り付けオプションを使ってキャンペーンを作成し、エクスポートした内容を貼り付けます。
  4. テスト送信を行い、その後は他のキャンペーンと同様に送信します。

カスタムHTMLを受け付けるESPであれば、Mailchimp、Brevo、SendGrid、Klaviyo、Campaign Monitor、ActiveCampaign、HubSpot、Mailjetなど、どれでも使用できます。

ESP側で引き続き行うこと

  • 配信、ドメイン認証(SPF/DKIM/DMARC)、リスト管理、配信停止、開封・クリックトラッキングです。配信停止用のマージタグやフッターの要件は、そのESPが期待する形式のまま維持してください。

送信後にMailInAppが行うこと

  • 投票、評価、フォーム送信を記録するインタラクションエンドポイントをホスティングします。
  • ライブビューとホスティングされたフォームページをホスティングします。
  • プロジェクトごとにインタラクション分析を集計します。

Gmailの102KBルール

Gmailは、HTMLが約102KBを超えるメッセージを切り詰め、残りの部分を「メッセージ全体を表示」というリンクに置き換えます。切り詰められたメッセージは<style>ブロックを失うため、すべてのキネティックなインタラクティブ性が黙って無効化されます。

スタジオは、デザイン中にコンパイル後のサイズをこの上限と照らし合わせて追跡し、上限に近づくと警告します。上限に達してしまった場合は、文章を短くする、使っていないブロックを削除する、画像に視覚的な役割を任せる(画像のバイト数はカウントされず、HTMLのみが対象です)といった対応を行ってください。

送信前にテストする

レンダリングの不具合は本番環境で発生しがちです。実際に送信する前に:

  1. 実際のESPを通してテスト送信を行います(ESPによってはHTMLをわずかに書き換えることがあります)。
  2. Gmailのウェブ版とスマートフォンで開いて確認します。
  3. 受信者に企業の担当者が含まれる場合は、クラシックOutlookで確認してください — レイアウトが崩れるのではなく、意図したOutlook用ティアが表示されるはずです。