オンライン サイトから広告キャンペーンに関するデータをどのように収集したか (製品への茨の道)

オンライン広告の分野は可能な限り技術的に進歩し、自動化されるべきだと思われます。もちろん、Yandex、Mail.Ru、Google、Facebook などの大手企業やその分野の専門家がそこで働いているからです。しかし、結局のところ、完璧には限界がなく、常に自動化できるものは存在します。

ソース

コミュニケーショングループ 電通イージス・ネットワーク・ロシア はデジタル広告市場の最大手であり、テクノロジーに積極的に投資し、ビジネス プロセスの最適化と自動化に努めています。オンライン広告市場の未解決の問題の 1 つは、さまざまなインターネット プラットフォームから広告キャンペーンに関する統計を収集するという課題になっています。この問題を解決するために、最終的に製品が誕生しました。 D1.デジタル (ディヴァンと読みます) の開発について話したいと思います。

なぜですか？

1. プロジェクトの開始時点では、広告キャンペーンの統計収集を自動化するという問題を解決する既製の製品は市場にひとつもありませんでした。 これは、私たち以外に私たちのニーズを満たしてくれる人はいないということを意味します。

Improvado、Roistat、Supermetrics、SegmentStream などのサービスは、プラットフォーム、ソーシャル ネットワーク、Google Analitycs との統合を提供し、広告キャンペーンの便利な分析と制御のための分析ダッシュボードを構築することも可能にします。製品の開発を開始する前に、これらのシステムのいくつかを使用してサイトからデータを収集しようとしましたが、残念ながら問題を解決できませんでした。

主な問題は、テストされた製品がデータ ソースに依存し、サイトごとの掲載順位の統計を表示し、広告キャンペーンの統計を集計する機能を提供していないことでした。このアプローチでは、さまざまなサイトの統計を 1 か所で確認したり、キャンペーン全体の状態を分析したりすることはできませんでした。

もう 1 つの要因は、初期段階では製品が西側市場を対象としており、ロシアのサイトとの統合をサポートしていなかったことです。また、統合が実装されたサイトでは、必要なすべてのメトリクスが必ずしも十分な詳細とともにダウンロードされるとは限らず、特にシステム インターフェイスにないものを取得する必要がある場合、統合は必ずしも便利で透過的であるとは限りませんでした。
一般に、私たちはサードパーティ製品に適応しないことを決定し、独自の製品の開発を開始しました。

2. オンライン広告市場は年々成長しており、2018年には広告予算で従来最大だったテレビ広告市場を追い抜きました。 だからスケールがあるんだよ.

3. 商業広告の販売が独占されているテレビ広告市場とは異なり、インターネット上ではさまざまな規模の広告在庫を所有し、独自の広告アカウントを持った個人所有者が多数存在します。広告キャンペーンは原則として複数のサイトで同時に実施されるため、広告キャンペーンの状況を把握するには、すべてのサイトからレポートを収集し、全体像を示す XNUMX つの大きなレポートにまとめる必要があります。 これは、最適化の可能性があることを意味します。

4. インターネット上の広告在庫の所有者は、統計を収集して広告アカウントに表示するためのインフラストラクチャをすでに備えており、このデータ用の API を提供できるように思えます。 つまり、技術的には実装可能ということになります。 それはそれほど単純ではないことが判明したとすぐに言ってみましょう。

一般に、プロジェクトを実装するための前提条件はすべて私たちにとって明らかであり、私たちはプロジェクトを実現するために全力を尽くしました...

グランドプラン

まず、私たちは理想的なシステムのビジョンを形成しました。

• 1C 企業システムからの広告キャンペーンは、名前、期間、予算、およびさまざまなプラットフォーム上の配置とともに、XNUMXC 企業システムに自動的にロードされる必要があります。
• 広告キャンペーン内の各配置について、インプレッション数、クリック数、ビュー数など、配置が行われているサイトからすべての可能な統計を自動的にダウンロードする必要があります。
• 一部の広告キャンペーンは、Adriver、Weborama、DCM などのいわゆる広告システムによるサードパーティのモニタリングを使用して追跡されます。ロシアにはメディアスコープ社という産業用インターネットメーターもあります。私たちの計画によれば、独立系および業界の監視からのデータも、対応する広告キャンペーンに自動的にロードされる必要があります。
• インターネット上のほとんどの広告キャンペーンは、特定のターゲット アクション (購入、電話、試乗への申し込みなど) を目的としており、Google Analytics を使用して追跡されます。また、その統計は、キャンペーンのステータスを理解するためにも重要です。ツールにロードする必要があります。

最初のパンケーキは塊状です

ソフトウェア開発の柔軟な原則 (アジャイル、すべて) への取り組みを考慮して、私たちは最初に MVP を開発し、次に意図された目標に向かって反復的に進むことにしました。
製品に基づいて MVP を構築することにしました DANBo (電通イージス・ネットワーク理事会)、これは、クライアントの広告キャンペーンに関する一般的な情報が含まれる Web アプリケーションです。

MVP では、プロジェクトは実装に関して可能な限り簡素化されました。統合するプラットフォームの限定されたリストを選択しました。これらは、Yandex.Direct、Yandex.Display、RB.Mail、MyTarget、Adwords、DBM、VK、FB などの主要なプラットフォームと、主要な広告システムである Adriver および Weborama でした。

API 経由でサイトの統計にアクセスするには、単一のアカウントを使用しました。広告キャンペーンに関する統計の自動収集を使用したいクライアント グループ マネージャーは、まずサイト上の必要な広告キャンペーンへのアクセスをプラットフォーム アカウントに委任する必要がありました。

次はシステムユーザーです ダンボー 特定の形式のファイルを Excel システムにアップロードする必要がありました。このファイルには、掲載に関するすべての情報 (広告キャンペーン、プラットフォーム、フォーマット、掲載期間、計画された指標、予算など) と、対応する広告キャンペーンの識別子が含まれていました。広告システムのサイトとカウンター。

率直に言って、それは恐ろしく見えました。

ダウンロードされたデータはデータベースに保存され、その後、別のサービスがサイト上のキャンペーン ID を収集し、それらの統計情報をダウンロードしました。

サイトごとに個別の Windows サービスが作成され、サイトの API の 1 つのサービス アカウントに 1 日に 1 回アクセスされ、指定されたキャンペーン ID の統計がダウンロードされました。広告システムでも同じことが起こりました。

ダウンロードされたデータは、小さなカスタム ダッシュボードの形式でインターフェイスに表示されました。

私たちにとって予期せぬことに、MVP が機能し始め、インターネット上の広告キャンペーンに関する現在の統計をダウンロードし始めました。私たちはシステムをいくつかのクライアントに実装しましたが、拡張しようとしたときに深刻な問題に遭遇しました。

• 主な問題は、システムにロードするデータの準備が複雑であることでした。また、配置データはロードする前に厳密に固定された形式に変換する必要がありました。ダウンロード ファイルには、さまざまなサイトからのエンティティ識別子を含める必要がありました。技術的なトレーニングを受けていないユーザーにとって、サイト上のこれらの識別子がどこにあるのか、ファイル内のどこに入力する必要があるのか​​を説明するのは非常に難しいという事実に直面しています。サイトでキャンペーンを実施している部門の従業員の数と売上高を考慮すると、結果的に私たち側からは多大なサポートを受けることになりましたが、これには全く満足できませんでした。
• もう 1 つの問題は、すべての広告プラットフォームに、広告キャンペーンへのアクセスを他のアカウントに委任するメカニズムがあるわけではないということでした。しかし、たとえ委任メカニズムが利用可能だったとしても、すべての広告主が自社のキャンペーンへのアクセスをサードパーティのアカウントに許可しようとするわけではありません。
• 重要な要因は、ユーザーがすでに 1C 会計システムに入力しているすべての計画された指標と配置の詳細を再入力する必要があるという事実によってユーザーの間で引き起こされた憤りでした。 ダンボー.

このことから、配置に関する情報の主な情報源は、すべてのデータが正確かつ時間どおりに入力される 1C システムであるべきであるという考えが生まれました (ここでのポイントは、請求書は 1C データに基づいて生成されるため、1C にデータを正しく入力する必要があるということです)はすべての KPI にとって優先事項です）。こうして、システムの新しい概念が生まれました...

コンセプト

私たちが最初に決めたのは、インターネット上の広告キャンペーンの統計を収集するシステムを別の製品として分離することでした。 D1.デジタル.

新しいコンセプトでは、 D1.デジタル 広告キャンペーンとその中のプレースメントに関する情報を 1C から取得し、サイトと AdServing システムからこれらのプレースメントに対する統計を取得します。これにより、ユーザーの作業が大幅に簡素化され (そして、いつものように、開発者の作業が増えます)、サポートの量が削減されるはずでした。

私たちが遭遇した最初の問題は組織的な性質のもので、さまざまなシステムのエンティティを 1C のキャンペーンやプレースメントと比較できるキーや記号が見つからないという事実に関連していました。実際、当社のプロセスは、広告キャンペーンがさまざまな担当者 (メディア プランナー、バイイングなど) によってさまざまなシステムに入力されるように設計されています。

この問題を解決するには、異なるシステム内のエンティティをリンクし、ダウンロードされたデータ セット内で非常に簡単かつ一意に識別できる一意のハッシュ キー DANBoID を発明する必要がありました。この識別子は、個々のプレースメントごとに内部 1C システムで生成され、すべてのサイトおよびすべての AdServing システムのキャンペーン、プレースメント、カウンタに転送されます。すべてのプレースメントに DANBoID を配置する実践には時間がかかりましたが、なんとか実行できました :)

その後、すべてのサイトに統計を自動的に収集するための API があるわけではなく、API がある場合でも、必要なすべてのデータが返されるわけではないことがわかりました。

この段階で、統合するプラットフォームのリストを大幅に減らし、大部分の広告キャンペーンに関与する主要なプラットフォームに焦点を当てることにしました。このリストには、広告市場 (Google、Yandex、Mail.ru)、ソーシャル ネットワーク (VK、Facebook、Twitter)、主要な AdServing および分析システム (DCM、Adriver、Weborama、Google Analytics) およびその他のプラットフォームの最大手企業がすべて含まれています。

私たちが選択したサイトの大部分には、必要な指標を提供する API がありました。 API が存在しないか、必要なデータが含まれていない場合は、オフィスの電子メールに毎日送信されるレポートを使用してデータをロードしました (一部のシステムではそのようなレポートを構成できますが、他のシステムでは、そのようなレポートは私たちに提供されます）。

さまざまなサイトからのデータを分析したところ、エンティティの階層がシステムごとに同じではないことがわかりました。さらに、情報はさまざまなシステムからさまざまな詳細でダウンロードする必要があります。

この問題を解決するために、SubDANBoID コンセプトが開発されました。 SubDANBoID のアイデアは非常に単純です。生成された DANBoID でサイト上のキャンペーンの主要なエンティティをマークし、一意のサイト識別子を持つすべてのネストされたエンティティをアップロードし、DANBoID 原則 + 第 1 レベルの識別子に従って SubDANBoID を形成します。ネストされたエンティティ + 第 2 レベルのネストされたエンティティの識別子 +... このアプローチにより、異なるシステムの広告キャンペーンを接続し、それらの詳細な統計をダウンロードすることができました。

また、さまざまなプラットフォームでのキャンペーンへのアクセスの問題も解決する必要がありました。上で述べたように、キャンペーンへのアクセスを別の技術アカウントに委任するメカニズムは、常に適用できるわけではありません。したがって、トークンを使用した OAuth による自動認証のインフラストラクチャと、これらのトークンを更新するメカニズムを開発する必要がありました。

この記事の後半では、ソリューションのアーキテクチャと実装の技術的な詳細について詳しく説明します。

ソリューション アーキテクチャ 1.0

新しい製品の実装を開始する際、新しいサイトに接続できる機能を直ちに提供する必要があることを理解し、マイクロサービス アーキテクチャの道を進むことにしました。

アーキテクチャを設計する際、すべての外部システム (1C、広告プラットフォーム、広告システム) へのコネクタを別個のサービスに分離しました。
主な考え方は、サイトへのすべてのコネクタが同じ API を持ち、サイト API を便利なインターフェイスに提供するアダプターであるということです。

当社製品の中心となるのは Web アプリケーションです。これは、簡単にサービスに分解できるように設計されたモノリスです。このアプリケーションは、ダウンロードされたデータを処理し、さまざまなシステムからの統計を照合し、それらをシステム ユーザーに提示する役割を果たします。

コネクタと Web アプリケーションの間で通信するには、コネクタ プロキシと呼ばれる追加のサービスを作成する必要がありました。サービスディスカバリとタスクスケジューラの機能を実行します。このサービスは、各コネクタのデータ収集タスクを毎晩実行します。サービス層の作成はメッセージ ブローカーに接続するよりも簡単で、私たちにとってはできるだけ早く結果を得ることが重要でした。

開発の簡素化と迅速化のため、すべてのサービスを Web API にすることも決定しました。これにより、概念実証を迅速に組み立て、設計全体が機能することを検証することが可能になりました。

別のかなり複雑なタスクは、さまざまなアカウントからデータを収集するためのアクセスを設定することでしたが、これはユーザーが Web インターフェイスを介して実行する必要があると判断しました。これは 2 つの別々の手順で構成されます。まず、ユーザーは OAuth 経由でアカウントにアクセスするためのトークンを追加し、次に特定のアカウントからクライアントのデータの収集を構成します。すでに書いたように、サイト上の目的のアカウントにアクセスを委任できるとは限らないため、OAuth 経由でトークンを取得することが必要です。

サイトからアカウントを選択するための汎用メカニズムを作成するには、JSON スキーマを返すメソッドをコネクタ API に追加する必要がありました。JSON スキーマは、変更された JSONEditor コンポーネントを使用してフォームにレンダリングされます。このようにして、ユーザーはデータをダウンロードするアカウントを選択できるようになりました。

サイトに存在するリクエスト制限に準拠するために、1 つのトークン内の設定リクエストを結合しますが、異なるトークンを並行して処理できます。

Web アプリケーションとコネクタの両方に読み込まれるデータのストレージとして MongoDB を選択しました。これにより、アプリケーションのオブジェクト モデルが 1 日おきに変更される開発の初期段階で、データ構造についてあまり心配する必要がなくなります。

すべてのデータが MongoDB に適切に適合するわけではないことがすぐにわかりました。たとえば、毎日の統計をリレーショナル データベースに保存する方が便利です。したがって、データ構造がリレーショナル データベースにより適しているコネクタについては、ストレージとして PostgreSQL または MS SQL Server を使用し始めました。

選択したアーキテクチャとテクノロジーにより、D1.Digital 製品を比較的迅速に構築して発売することができました。 23 年間の製品開発を通じて、私たちはサイトへの 3 のコネクタを開発し、サードパーティ API を使用した貴重な経験を積み、それぞれに独自の異なるサイトの落とし穴を回避する方法を学び、少なくとも 15 つの API の開発に貢献しました。のサイトでは、約 000 のキャンペーンと 80 を超えるプレースメントに関する情報が自動的にダウンロードされ、製品の操作に関するユーザーからの多くのフィードバックが収集され、このフィードバックに基づいて製品の主要なプロセスを数回変更することができました。

ソリューション アーキテクチャ 2.0

開発開始から2年が経過 D1.デジタル。システムの負荷が継続的に増加し、新しいデータ ソースがどんどん登場することで、既存のソリューション アーキテクチャの問題が徐々に明らかになりました。

最初の問題は、サイトからダウンロードされるデータの量に関連しています。私たちは、大規模なサイトから必要なデータをすべて収集して更新するには時間がかかりすぎるという事実に直面しました。たとえば、ほとんどの広告枠の統計を追跡する AdRiver 広告配信システムからデータを収集するには、約 12 時間かかります。

この問題を解決するために、私たちはサイトからデータをダウンロードするためにあらゆる種類のレポートを使用し始めました。私たちは、その動作速度がニーズを満たすようにサイトと共同で API を開発し、データのダウンロードを可能な限り並列化しようとしています。

もう 10 つの問題は、ダウンロードされたデータの処理に関連しています。現在、新しい掲載枠統計が到着すると、指標を再計算する多段階のプロセスが開始されます。これには、生データの読み込み、各サイトの集計指標の計算、異なるソースからのデータの相互比較、キャンペーンの概要指標の計算が含まれます。これにより、すべての計算を行う Web アプリケーションに多大な負荷がかかります。再計算プロセス中に、アプリケーションがサーバー上のすべてのメモリ (約 15 ～ XNUMX GB) を消費することが何度かあり、これがユーザーのシステム作業に最も悪影響を及ぼしました。

特定された問題と製品のさらなる開発に向けた野心的な計画により、アプリケーション アーキテクチャを再検討する必要があることがわかりました。

まずはコネクタから始めました。
すべてのコネクタが同じモデルに従って動作することに気付き、ステップのロジックをプログラムするだけでコネクタを作成できるパイプライン フレームワークを構築し、残りは汎用的に行うことができました。コネクタに改善が必要な場合は、コネクタの改善と同時に、コネクタを直ちに新しいフレームワークに移行します。

同時に、Docker と Kubernetes へのコネクタのデプロイを開始しました。
私たちはかなり長い間 Kubernetes への移行を計画し、CI/CD 設定を実験しましたが、移行を開始したのは、エラーにより 20 つのコネクタがサーバー上の XNUMX GB 以上のメモリを使い始め、実質的に他のプロセスが停止したときだけでした。 。調査中に、コネクタは Kubernetes クラスターに移動され、エラーが修正された後も最終的にはそこに残りました。

私たちは Kubernetes が便利であることをすぐに認識し、7 か月以内に、最も多くのリソースを消費する XNUMX つのコネクタとコネクタ プロキシを実稼働クラスタに移行しました。

コネクタに続いて、アプリケーションの残りの部分のアーキテクチャを変更することにしました。
主な問題は、データがコネクタから大規模なバッチでプロキシに送信され、その後 DANBoID に到達し、処理のために中央の Web アプリケーションに送信されることでした。メトリクスの再計算が多数行われるため、アプリケーションに大きな負荷がかかります。

また、個々のデータ収集ジョブのステータスを監視し、コネクタ内で発生したエラーを中央の Web アプリケーションに報告して、何が起こっているのか、なぜデータが収集されないのかをユーザーが確認できるようにすることは、非常に難しいことも判明しました。

これらの問題を解決するために、私たちはアーキテクチャ 2.0 を開発しました。

新しいバージョンのアーキテクチャの主な違いは、サービス間でメッセージを交換するために Web API の代わりに RabbitMQ と MassTransit ライブラリを使用することです。これを行うには、コネクタ プロキシをほぼ完全に書き直し、コネクタ ハブにする必要がありました。このサービスの主な役割は、リクエストをコネクタに転送したり、コネクタに戻したりすることではなく、コネクタからのメトリクスの収集を管理することにあるため、名前が変更されました。

中央の Web アプリケーションから、サイトからのプレースメントと統計に関する情報を個別のサービスに分離しました。これにより、不必要な再計算を排除し、プレースメント レベルですでに計算および集計された統計のみを保存できるようになりました。また、生データに基づいて基本統計を計算するロジックも書き直して最適化しました。

同時に、ソリューションの拡張と管理をより容易にするために、すべてのサービスとアプリケーションを Docker と Kubernetes に移行しています。

私たちは今どこにいますか

概念実証アーキテクチャ 2.0 製品 D1.デジタル 準備が整い、限られたコネクタのセットを備えたテスト環境で動作します。あとは、さらに 20 個のコネクタを新しいプラットフォームに書き換え、データが正しくロードされ、すべてのメトリクスが正しく計算されていることをテストし、設計全体を運用環境に展開するだけです。

実際、このプロセスは段階的に行われるため、すべてが機能し続けるためには古い API との下位互換性を残す必要があります。

当社の当面の計画には、新しいコネクタの開発、新しいシステムとの統合、接続されたサイトや広告システムからダウンロードされたデータセットへの追加のメトリクスの追加が含まれます。

また、中央の Web アプリケーションを含むすべてのアプリケーションを Docker と Kubernetes に移行する予定です。新しいアーキテクチャと組み合わせることで、消費されるリソースの展開、監視、制御が大幅に簡素化されます。

もう 1 つのアイデアは、現在 MongoDB に保存されている統計を保存するためのデータベースの選択を実験することです。すでにいくつかの新しいコネクタを SQL データベースに移行しましたが、その違いはほとんど目立ちません。また、任意の期間にわたって要求できる日ごとの集計統計の場合、その効果は非常に深刻になる可能性があります。

一般的に、計画は壮大です。先に進みましょう:)

記事執筆者 R&D Dentsu Aegis Network Russia: Georgy Ostapenko (シミガー)、ミハイル・コツィク(ひてっくす)

出所： habr.com