完全なメールマーケティングサービスを構築するのはどれくらい難しいですか? このために何を想定する必要がありますか? 開発者の心を探求する過程で、どんな落とし穴に遭遇する可能性がありますか?

一緒に考えてみましょう。 いくつかの記事では、私が1年でどのように自分のメールニュースレターサービスを作成したか、自分自身のために学んだ教訓、そしてこれらすべてで次に何をするつもりかについて話します。
記事が問題の技術面のみを考慮していることを直ちに予約してください。
自分について簡単に
私は5年間Pythonで書いてきました。主にPostgreSQLのDjangoを使用しています。jQuery+ KnockoutJSレベルでJavaScriptを準備できます。 メインの仕事からの空き時間に、フリーランスの仕事と自分のインターネットプロジェクトを行います。 私はこのプロジェクトを約1年間やっています。
プロジェクト目標
冒頭で、私はかなり簡単な目標を設定しました-開封、変換、手紙の配信不能、スパムに関する苦情を追跡する機能を備えたトランザクションレターとメールニュースレターを送信するための実用的なソリューションを作成します。 以前使用していたYandex SDA(ドメインのメール)にはそのような機能はありませんでしたが、必要だったため、このソリューションを他のプロジェクトで使用することを計画しました。
そして、このソリューションをインターネット上のすべてのユーザーにSaaSの形で提供することに疑問はありませんでした。
タスク
- メールニュースレターでイベントトラッキングがどのように機能するかを理解し、トラッキングを処理します。
- 平均的な負荷(1か月あたり200〜300万文字)で機能するソリューションを考え出します。 なぜ正確に2〜3百万人ですか? 私は、そのようなプロジェクトを回収するために、そのような量が必要であると信じています(費やした時間+サーバーなどの重要なリソース)。
- バルクおよびトランザクションメーリングの分析用の便利なインターフェイスを実装します。
さらに、これらの各タスクをどのように達成したかについて、多少詳しく説明します。
技術
私は、Python、Django、PostgreSQL、KnockoutJS、LESS、py.testなどの既知のテクノロジーを使用することにしました。
さらに、プロジェクトに取り組む過程で、Celeryとマイクロサービスアーキテクチャについて十分に理解しました。
これについては、入門部分を終了し、最も興味深い部分である練習に移ることを提案します。
メール追跡はどのように機能しますか?

メールを送信するとき、おそらく、手紙が受信者に送信されたかどうか、読んだかどうか、興味を持ったかどうか、手紙のリンクをたどったかどうか、その後サイトで何をしたか、ターゲットアクションを実行したかどうか、つまり購入、注文、電話など。
これらの質問に対する回答を得るには、追跡またはYandex.Metricaなどのシステムを使用する必要があります(まあ、または受信者に直接尋ねることで)。
メール検出の追跡
今日、レターの開始を追跡する標準的なアプローチは、レターに特別なピクセルを埋め込むことです。レターのソースを見ると、受信ボックスのほとんどの広告レターでこのピクセルを見ることができます。 次のようになります。
<img src="http://api.mailhandler.ru/message/track/<UNIQUE_EMAIL_ID>/OPENED/" width="1px" height="1px" border="0"/>
画像の
src属性で指定されたURLを要求するときにイベントを追加する必要があることは明らかです。つまり、
IDが
UNIQUE_EMAIL_IDに等しい文字が開かれたことを
意味します。
ただし、すべてがそれほど単純ではありません。 多くの場合、src画像では、いくつかのphpスクリプトにつながるURLを示しており、メールサービスが画像自体だけでなく画像に有効なヘッダーを本当に受信したいとは思わない。 この理由でメールサービスがピクセルで失望した場合、メールから切り落とされるだけで、宛先がレターを開いたかどうかはわかりません。
これを防ぐには、正しい応答ヘッダーを追加し、有効な画像をクライアントに提供する必要があります。 Django Rest Frameworkの実装は次のようになります。
class TrackMessageView(APIView): renderer_classes = [JPEGRenderer] @property def pixel(self): return open(os.path.join(settings.STATIC_ROOT, 'site/img/pixel.jpg'), 'rb') def get(self, request, *args, **kwargs): manager = BaseManager() message = manager.get_message_by_unique_id(self.kwargs['unique_id']) if message: manager.track_message(message) return Response(self.pixel.read(), status=201) return Response(status=404)
メールでリンクのクリックを追跡する

好奇心itive盛な読者には、この種の追跡の実装に問題はないはずです。 通常、レターの各リンクは、「リンクをフォローする」などのイベントを作成する特別なリダイレクトサービスを介したリンクに置き換えられます。 さらに、各リンクに一意の識別子を追加することができます-その後、レターの「ヒートマップ」を実装できます。 これは、A / Bテストなどに非常に便利な機能です。
Pythonの実装は非常にシンプルに見えます。
REDIRECT_URL_TEMPLATE = '%s/message/redirect/%s/' HREF_REGEXP = r'(?<=href=(\"|\'))(http|https)([^\"\']+)(?=(\"|\'))' ... def replace_links(message): redirect_url = REDIRECT_URL_TEMPLATE % (settings.API_URL, message.unique_id) message.html_body = re.sub(HREF_REGEXP, r'%s?next=\2\3' % redirect_url, message.html_body) ...
配送エラーの追跡
しかし、これにより、すべてがはるかに興味深いものになります。
メールサーバーがレターを配信できないたびに、送信者のアドレスへの返信により、配信の不可能性に関するレポートに理由の説明が含まれます(詳細な場合もあります)。 これらの着信レターを処理するために、
/ etc / aliasesを介してハンドラースクリプトを使用して着信レターをPythonに転送するというアプローチを使用しました。
分析用の手紙の一例:
Final-Recipient: rfc822; ****@****.ru Original-Recipient: rfc822; ****@****.ru Action: failed Status: 4.4.1 Diagnostic-Code: X-Postfix; connect to ****.ru[xx.xx.xxx.xxx]:25: Connection refused
スクリプト自体は、メッセージを配信できない理由を多かれ少なかれ知的に理解しようとし、ソフトバウンスイベント(
現時点では手紙を配信できませんが、再試行できます)またはハードバウンス(メッセージ
は配信されないなど)を作成します存在しません)。
ここでは、Mail.ru、Yandexなどのメールサービスのルールに従って、そのようなイベントに実際に応答する方法について小さな発言をすることが重要です。
サブスクリプションベースのメーリングサービスは、無条件にサブスクライバデータベースから削除するか、SMTPプロトコルエラーを生成するアドレスへのメーリングを一時停止する手段を講じる必要があります。
»
ルールのリストへのリンクしたがって、メールの配信が不可能なアドレスへのサブスクライバーの「シャットダウン」を提供する必要がありました。 その結果、サービスのすべてのサブスクライバーリストからサブスクライバーをオフにするという結論に達しました。
まあ、それは追跡で整理されているようです。
いくつかの統計
現在、1か月あたり約150,000通の手紙が私のサービスを通じて送信されています。 それはたくさんですか、それとも少しですか? 指定されたタスクのフレームワークに自分で設定したボリュームを考えると、おそらく十分ではありません。
それらのうち:
- 20%が開いています(これはかなり大きな割合です。実際、トランザクションメールのおかげです)
- 13%-クリックスルー
- 9%-ハード/ソフトバウンス
PS
次の記事では、このデータをどのように、どのように処理するかについて説明し、そのようなプロジェクトでセロリを使用することの複雑さについて説明します。また、このサービスで行う予定にさらに焦点を当てます。
ご清聴ありがとうございました!