メッセージボードのコンテキスト広告におけるバックパックの問題

ここでは、コンテキスト広告キャンペーンの1日の予算制限を管理するための（私の意見では）最良の方法の1つを紹介したいと思います。このようなスキームは、トラフィックを間接的に収益化する企業、たとえば、分類、自動車、不動産、および世界中のあらゆるものに適しているように思われます。おそらく彼らだけではありません。



公開記事を書くのはこれが初めてですが（2回目です）、問題が発生した場合は申し訳ありません。建設的なコメントをいただければ幸いです。

直接収益化してみませんか？

収益化が直接でROIが十分に計算されている企業は、投資が報われる限り、その容量の限界まで広告ソースに投資する余裕があるためです。一方、メッセージボードのようなサイトはしばしばそれを買う余裕がありません。なぜなら 投資収益率との厳密な関係はありません。商品やサービス自体を販売するのではなく、広告モデルに従って機能します。簡単に言えば、今日は状況に応じて多くのお金を使うことができますが、明日は分類されたサイトでの広告契約が増えることはありません。



したがって、このようなサイトの場合、コンテキスト広告から引き付けられたトラフィックは、時間遅延を伴って間接的に収益化され、トラフィックの一部のみが、たとえば通話で直接収益化されます。





このエッセイの目的のために、来月の予算と有効な広告アカウントを備えたメディアプランがすでにあると仮定しましょう。次は何ですか？

これらの会社の広告アカウントは通常どのように見えますか？

1. ほとんどの場合、少なくとも2つの広告アカウントがあります。YandexDirectとGoogleAds、そしてこの点で、私たちは非常に幸運です。なぜなら、競争は常に存在しないよりも優れているからです。これは健全な最適化のための優れた分野です。
2. たとえば、コンバージョン、プロジェクト、サポートチーム、または別の基準でのキャンペーンがアカウントごとに分割されているため、さらに多くの広告アカウントが存在する可能性があります。
3. 各広告アカウントには一連の広告キャンペーン（AC）が含まれます。たとえば、名前がキャンペーンを分類する何らかの方法を示しているとします（たとえば、地域別、プロジェクト別、プレースメントの種類別、プラットフォーム別）。

一般に、すべての広告キャンペーンの数が非常に多く、たとえば数千のオーダーである場合、状況は完全に正常です。もちろん、それらは何らかの形でクラスター化されており、原則として、そこにロジックがあります。これに従って、キャンペーンの1つまたは別のサブセットを選択して、統計を表示したり、設定を修正したり、大幅な変更を加えたりできます。





ACのセットが非常に多いため、1日の予算を手動で計算して割り当てることは非常に困難です。このプロセスの自動化の説明を扱います。

来月のメディアプランを見てみましょう

翌月の予算が設定されているすべての分類記号の組み合わせをメディアプランノードと呼びましょう。定義済み（地域、製品、取引の種類、リースやセールなど）と予算があるとします。



ほとんどの場合、MT内のサイトには、予算だけでなく、変換コストの目標も設定されます。私の意見では、重要な発言をさせてください。

1日の予算を割り当て、MTを予算内で達成する場合、コンバージョンあたりのコストの目標はまったく関係ありません。ですから、今はそれらを見ていません。

問題の定式化

あなたはこの世界で何が起こっているのか決してわかりません、私はほぼ確実に次の声明を確信しています：

メディアプランノードの数は、常にすべてのアカウントの広告キャンペーンの数以下になります。

このレンマの導入後、パッケージがメディアプランノードに対応するように、広告キャンペーンをパッケージに結合することについて話すことができます。これで、タスクは次のように定式化されます。

特定の予算で購入したコンバージョンの数が最大になるように、キャンペーンの予算をまとめて配布する必要があります。

これは、古典的なナップザック問題の定式化と非常に似ているようです。予算のサイズはバックパックのボリュームとして使用され、変換のコストに関するデータは石の値として使用されます。しかし、これは部分的にしか真実ではありません。事実、広告キャンペーンの予算は（AC容量の制限まで）任意の方法で選択でき、バックパックの問題の石は分離できません。この問題にはバリエーションがあります-継続的なナップザックの問題。どうやらその言葉遣いはより適切であり、おそらくこれでさえそうです（これについて何かコメントがあれば、私はそれらを読んでうれしいです）。



問題の元の名前を間違えたにもかかわらず、貪欲なアルゴリズムを使用して適切な解決策を選択したようにも思えます。ナップザック問題を解決するためのアプローチと方法を理解したとき、私は自分のケースを解決するために動的プログラミング方法を適用することができませんでした（明らかに、理由は正確に分数にあります）。しかし、私の計算によれば、貪欲なアルゴリズムは、実際には、継続的なナップザックの問題を解決します。



簡単に言うと、バンドルキャンペーンは、コンバージョンあたりの実際のコストの昇順で並べる必要があります。より多くを費やすことができ、リストのトップにあるキャンペーンには、この機会を与える必要があります。予算が不足した場合にリストの一番下にあるキャンペーンは、最初に削減する必要があります。したがって、パッケージ内の指定された予算に対して最も安いRKの選択があります。

• - , , . .
• Google. :)

• , .. . . .
• , .. ,

• ( )

1. , Google Analytics
2. 結果のレポートはどこかに保存する必要があります。この場合は任意のデータベースが適していますが、私の好みで最も便利なのはGoogleBigQueryです。
3. Jupyterメモ帳を使用して、データを分析し、レポートを作成できます。Google Colabは、私の好みにも適しています、tk。簡単なチームワークが編成されます（Googleドキュメントのように）
4. 再予算を定期的に実行して統計を収集するサーバーが必要です。通常、このようなタスクには、ほとんどすべての標準のAWSまたはGoogleCloudクラウドサーバーで十分です。
5. リストの一番下にあるキャンペーンには、一時停止する前に最小予算を割り当てるオプションがあります。ただし、キャンペーンが長期間停止されている場合は、そのようなキャンペーンの定期的な「リハビリ」のメカニズムを検討し、コンバージョンのコストに関するデータをどこで入手するかという質問に答える必要があります。

これまでのところ、私はすべてを持っています。



清聴ありがとうございました。