次の方法で共有

Data Science ツールキット - カスタム モデルの実装前とトラブルシューティング ガイド

  • [アーティクル]

このページでは、カスタム モデルの実装を準備するためのベスト プラクティスと、カスタム モデルの使用によって発生する可能性がある一般的な問題のガイドについて説明します。

実装前のベスト プラクティス

カスタム モデルの目的

カスタム モデルは、インプレッションをターゲットにする方法ではなく、インプレッションの価格を決定するために設計されています。 ターゲティングインプレッションの場合は、 で設定された広告申込情報の [ターゲット設定 ] セクション、または API を使用してターゲット設定を行う プロファイル サービス を引き続き使用する必要があります。 ただし、広告申込情報のターゲット設定は、カスタム モデルの機能と一致する必要があります。 2 つの間の不一致により、1 行の配信が制限される可能性があります。

構文とアクセス許可のガイダンス

  • カスタム モデルを作成して更新するには、ロール APB Bonsai ユーザー ロールまたは APB Genie ユーザー ロールを持つ Invest ユーザーから API 呼び出しを行う必要があります。 シート内のユーザーが使用できるこれらのロールがまだ表示されていない場合は、製品サポート チケットを開きます。 多くのクライアントが新しいユーザーを作成し、カスタム モデルの更新専用に使用します。
  • ツリーを Xandr にアップロードする前に Base64 でエンコードし、Base64-Encoded ツリーが 3 MB 以下であることを確認します。
  • Bonsai モデルでは、スペースではなくインデントにタブを使用します。
  • ログ レベルのデータに関するレポートにラベルが残されます。 これにより、入札方法を正確に把握するのに役立ちます。
  • 特定の状況で入札しない場合は、"0" ではなく "no_bid" の単価または乗数を使用します。

容量の処理

  • 数分ごとに新しいモデルを作成するのではなく、古いモデルを更新します。
  • 未使用のモデルを定期的に削除するスクリプトを作成する

ログ レベルのデータの使用

カスタム モデルを正常に使用するには、パフォーマンスに基づいてモデルを更新する必要があります。 これは、次の 2 つのログ レベルのデータ フィードで実行できます。

  • カスタム モデル フィード: このフィードは、広告申込情報に関連付けられているモデルと、それらのモデルによって計算された値に関する情報を提供します。
  • 標準フィード: このフィードは、取引されたインプレッションに関する情報を提供します。

また、 ここに 記載されているログ レベルのデータ フィードからデータを収集し、関連する場合はカスタム モデルにデータを含めることもできます。

トラブルシューティング ガイド

行項目が予期した結果を提供せず、カスタム モデルがアタッチされている場合は、次のトラブルシューティング手順に従います。

手順 1: カスタム モデルが問題であるかどうかを判断する

行項目が期待どおりに配信されていない場合は、アタッチされたカスタム モデルが問題の原因になっている可能性があります。 使用するカスタム モデルのトラブルシューティングを行う前に、行項目の設定によって配信の問題が発生しないことを確認することをお勧めします。 行項目とその親オブジェクトにチェックする一般的な項目は次のとおりです。

  • 明細はアクティブで、フライトの日付内ですか? 親の挿入順序はどうですか?
  • ターゲット設定は非常に制限が厳しく、入札する在庫の量を制限していますか? たとえば、一握りの郵便番号や小さなセグメントのみを対象にしていますか? Planner ツールを使用して、キャンペーンのリーチと、各ターゲティング設定がキャンペーンに与える影響を把握します。
  • 広告申込情報のトラブルシューティング タブを使用して、広告申込情報がインプレッションを失っている入札じょうごのポイントを特定します。 [トラブルシューティング] タブには、インベントリがフィルター処理されている理由が示され、そのタブで推奨される次の手順を実行すると、支出が増えるのに役立ちますか? トラブルシューティング タブの詳細については、 こちらを参照してください。

拡張広告申込情報のトラブルシューティングの詳細については、拡張広告申込情報 の配信と入札パフォーマンスのトラブルシューティング に関するドキュメントを参照してください。

行項目のトラブルシューティングでパフォーマンスの問題が解決しない場合は、次の手順に進み、カスタム モデルのトラブルシューティングを行います。

手順 2. 広告申込情報が入札の対象かどうかを確認する

カスタム モデルでは、広告申込情報のターゲット設定によって入札額を決定するために使用される機能が除外されている場合、広告申込情報の使用を妨げる可能性があります。 この状況の例を次に示します。

  • クリエイティブ選択モデルのクリエイティブ ID は、広告申込情報のクリエイティブ ID と同じではありません。
  • この広告申込情報はニューヨークの郵便番号を対象としていますが、カスタム モデルの郵便番号機能はカリフォルニア州の郵便番号用です。

次の手順に従って、カスタム モデルが広告申込情報と一致していることを確認します。

  • プラットフォームの API を使用して、チェックする行項目を取得します。

    curl -H 'Authorization: {api_token}' 'https://api.appnexus.com/line-item-model?id=123'

    次の応答が返されます。

    {
   "response": {
    "dbg_info": {...},
    "num_elements": null,
    "start_element": null,
    "count": 2,
    "line_item_models": {
            "1234567": [
                {
                    "line_item_id": 1234567,
                    "type": "cadence",
                    "custom_model_id": 32768053,
                    "origin": "optimization",
                    "experiment": "control",
                    "origin_id": "1"
                },
                {
                    "line_item_id": 1234567,
                    "type": "expected_value",
                    "custom_model_id": 45249297,
                    "origin": "client",
                    "experiment": "control",
                    "origin_id": "0"
        }
      ]
    },
    "status": "OK"
  }
}

    応答では、フィールドの配信元が最適化と等しい場合、これは Xandr カスタム モデルであることを意味します。 配信元フィールドがクライアントと等しい場合、ユーザーが行項目にアタッチしたカスタム モデルになります。 カスタム モデル ID とその型を書き留めます。

  • プラットフォームの API を使用して、各カスタム モデルの構造を取得します。

    $ curl -b cookies -c cookies 'https://api.appnexus.com/custom-model?id=45249297'

    カスタム モデルを読み取り、モデルで使用されるフィーチャが広告申込情報の設定と一致していることを確認します。 広告申込情報のターゲット設定は、カスタム モデルの機能と一致する必要があります。 2 つの間に不一致があると、行項目の消費が妨げる可能性があります。 簡単な例を次に示します。

  • 広告申込情報でセグメント 34567 をターゲットにしていても、ユーザーが 67890 に属している場合にのみ入札する場合、この広告申込情報は配信されません。 このカスタム モデルの目的は、行項目の目標と一致しません。 この種のトラブルシューティングを実行するには、カスタム モデルの 'if' と 'else' のロジックに従う必要があります。 また、モデルで使用されるフィーチャの値範囲も理解する必要があります。 一部の機能の例を次に示します。

    • セグメント
    • デバイス
    • 地理

注:

カスタム モデルのクリエイティブも広告申込情報に含まれていることを確認します。

カスタム モデルで使用できる機能の完全な一覧については、 Bonsai 言語機能に関するページを参照してください。 詳細については、「 ロジスティック回帰モデル」のロジスティック回帰モデルに関するドキュメントを参照してください。 

if not segment [11584384]:
  if segment [4558196].value > 2
      if segment [18332166]:
        if segment[19154661]:
          value: compute(segment[19154661]).value, 0.030000000000000002, 0, 10.0, 1000.0)
        else:
          0.01
      else:
        0.01
  else:
    0.01
else:
  value: 0.01

このモデルを見ると、次のように読むことができます。

ユーザーがセグメント ID 11584384に属していない場合は、

また 、ユーザーが 2 より大きい値を持つセグメント ID 4558196に属している場合は、

ユーザー がセグメント ID 18332166に属している場合は、

ユーザー がセグメント ID 19154661に属している場合は、

次に、セグメント値に乗数を乗算して動的値を計算します。

注:

値: compute(segment[19154661].value, 0.0300000000000000002, 0, 10.0, 10000.0) 構文は値です: compute(input_field, 乗数, オフセット, min_value, max_value). これは max(min_value, min(max_value, input_field * 乗数 + オフセット)) として評価されます。 つまり、ユーザー セグメントの値は 336 より大きくする必要があります。それ以外の場合は、最小値 10.0 が返されます。

上記の条件がすべて満たされていない場合は、ev_click モデルの値 0.01 を返します。

手順 3. ラインに勝てる入札価格があるかどうかを確認する

入札値の数式は、品目にアタッチされているカスタム モデルの種類によって異なります。 カスタム モデルが特定の入札値をどのように作成するかを理解するには、使用しているカスタム モデルの種類をチェックします。