AdWords API Workshops 2015 in Tokyoに参加してきた

参考になればシェアしてもらえるとうれしいです

  • このエントリーをはてなブックマークに追加
  • 8
20150417_175937_764
スポンサーリンク

目次

Adwords API Workshopsとは

全国9つの地域で開催している。

  • San Francisco (Technical) – March 23rd
  • New York (Technical) – March 30th
  • Hamburg (Technical) – April 2nd
  • Amsterdam (Technical) – April 7th
  • London (Technical) – April 10th
  • London (Introductory Technical) – April 13th
  • Beijing (Business) – April 14th
  • Tokyo (Advanced) – April 17th
  • Buenos Aires (Business) – April 21st
  • São Paulo (Business) – April 24th

APIを用いた開発者向けのイベント。
自動化という波をさらに促進させるための取り組みの一つではないか。

イベントで用いられたスライドは後日公開されるだろうが、書き起こしたものを公開します。

タイムテーブル

Time Activity Talk
13:00:00 Reception Coffee and cookie
13:15:00
13:30:00 Talks Introduction
13:45:00 Talks Keynote
14:00:00
14:15:00 Talks How AdWords maps into AdWords API
14:30:00
14:45:00 Talks Ad Customizers
15:00:00
15:15:00 Break
15:30:00 Talks Hard Feed Types or AdWords API and the mobile world
15:45:00
16:00:00 Upgraded URLs
16:15:00
16:30:00
16:45:00
17:00:00
17:15:00 Effective Reporting
17:30:00
17:45:00 Ending Q&A

イントロダクション

  • Developerチームはフィードバックを欲しがっている。
  • フィードバックには数字とユースケースが有効。

ex) 仕様そのままを適用できないイレギュラーがあるアカウントが300中280個ある。
 そのため機能を追加して欲しい。など

今回、話を進めていく上に際し、

  • MCCアカウントで複数アカウント管理
  • 中小のビジネスオーナーを顧客に持つ
  • 全ての顧客は楽器関係
  • 顧客は地元に実店舗を持つ
  • モバイルアプリもリリースしている

という架空の会社を想定し、Agendaを進めていく。

# 正直、そんな話は無かったw

KeyNote

新機能

アカウントレベルのラベルサポート

AccountLabelServicecを使いMCCアカウントレベルのラベルを利用可能に

→ APIでアカウント単位でラベルを振ることが出来る(「要チェック」などをバッチで回して機械でアラーティングを行う)

共有設定が復活

アカウントレベルでの

  • 除外キーワード
  • プレースメント

がなくなっていたが、フィードバックを受けて復活。

# v201409とv201502で両方で利用可能

Extension Setting Services

広告表示オプションに活用

改良版URL

トラッキング情報の設定を容易に。

A/Bテストに活用出来る?

# 詳細は後のどのセクションで。

最終URLへの移行をサポート

AdGroup AdservceがupgradeUrlメソッドをサポート

このメソッドを使った場合

  • 自動的にdestinationUrlをfinalUrlsへコピー
  • 広告IDは変化なし
  • 広告の再審査は発生しない

アプリディープリンク

広告内でアプリのアクションに直接結びつく

新しいレポート

  • 距離レポート(USER_AD_DISTANCE_REPORT
  • ラベル(LABEL_REPORT

レポート

HTTPへっだ skipColumnHeaderのサポートを追加

  • 生成されたレポートの列ヘッダーを削除
  • さらに;skipReportHeader、 skipReportSummaryも追加

→ 返却値をデータのみにできますよ

などなど多数。

詳しいことはリリースノートへ

予定されている廃止機能

v201406は完全廃止、v201502への移行を推奨

v201409の方はv201502への移行を推奨(次バージョンリリース時に廃止)

#次の次のバージョンが出ると過去のバージョンは廃止となる。

削除済みのオブジェクトは自動で返ってこなくなる。

predicateで指定することで返却可能

→ デフォルト値が変更された

#広告は以前からこの動作だった。キャンペーン・広告グループが今後この動作になる。

広告表示オプション

CampaignAdExtensionServiceは廃止

→代わりにFeedServicesとExtensionSettingを仕様

AD_EXTENSION_PERFORMANCE_REPORTは廃止

ExternalRemarketingUserListは廃止

DataServiceにおけるBid Landscapes無いのmarginalCpcは廃止

ProductTargetフィールドは廃止(PLA廃止に伴い)

詳細はリリースノートをご覧ください。

FeedItemService

validationDetailsフィールドは廃止

今後はpolicyDataを活用

Geo criteriaフィールドは返り値が整数に(Stringだった

GoogleAnalyticsの列タイトルがAdwordsユーザーインタフェースと対応

重複フィールドを廃止

Adwords UIとAPI

〜Adwords UIとAdwords APIの対応について〜

AdWords APIについて

AdwordsUIに実装されてからAdwordsAPIへと順次実装される。(Adwords APIへの提供の方が遅い)

AdWordsEditorの機能提供が遅いのはそのため。

認証

OAuth2で行う。

  • RefreshTokenを取得
  • 必要な全ての値をproperties/ini/configファイルに保存 (refreshToken , clientId, clientSecret, developerToken)
  • 残りは起動時にクライアントライブラリが処理

基本・キャンペーン、広告について

Adwordsオブジェクト

Adwordsはいくつかのオブジェクトから構成される

UI上ではそれぞれの基本オブジェクトはタブとして表現される

  1. アカウント
  2. キャンペーン
  3. 広告グループ
  4. 広告

上から順に固まりが大きい。

基本原則:オブジェクトごとに1種のサービス

  • get オブジェクトを取得Selectorで取得項目、条件を指定
  • query オブジェクトを取得。AWQLで取得高m苦、条件を指定
  • mutate 下記のoperatorを使用してオブジェクトを変更
    • ADD 新規オブジェクトを作成
    • SET オブジェクトを更新
    • REMOVE オブジェクトを削除

#一部のオブジェクトはINMUTIBLE(更新出来ない)、ものもあるのでリリースノートを確認。

基本的な流れ

xx一覧を取得・表示したい場合

  1. ServiceInterfaceを作成
  2. Selectorで条件を指定
  3. getなどで取得
  4. 取得した値を繰り返し出力

広告表示オプション

広告表示オプションはUIでは一つのタブにまとめられているが、APIでは

  • v201409: Feed Services (old)

汎用的なfeedを定義し、内容を追加、マッピングし情報を取得

  • v201502:ExtensionSettingService

レポーティング・API経由でのレポート取得

Adwordsダッシュボード

UI

グループごとに確認が出来る。

フィルタや期間でもカスタマイズ出来る。

API

ReportDownloderを使用したレポート機能(Javaの場合)

  • UIと同様、ストリームファイルとしてダウンロード可能
  • ReportDefinitionを使用してレポートタイプ。フィールド、フィルタ、フォーマットなどを定義可能

※AWQLでも代替可能

ほとんどの言語のクライアントライブラリにReportUtilityがあり、ダウンロードメソッドが提供されているはず。

Tips : 何かのMetricsを指定しないとレスポンスが返ってこない。(CampaignIDだけ返却することは不能)

並べ替え、ページネーション、スケジュール設定、メール送信はAPIではまだ未対応。

セグメンテーションは可能。

レポートタイプ

goo.gl/HlGePj

その他

レポートはただのHTTPリクエストだからUNIXシェルとかでも取れるw

cURLとかwgetでもヘッダにトークンを埋めればアクセスできる。

ex) Cronでレポート取って、sedで分割して、値が境界値を超えてたらmailコマンドでメールを送ることが可能。

雑談

ADD や UPDATEをする再、mutetdというメソッドで実装するのか、add~やupdate~やdelete〜のメソッドを個別に実装するかどちらがいいか。

会場内で挙手を獲った結果、半々くらいだった。

広告カスタマイザ

広告カスタマイザとは

  • リアルタイムでインスタンス化される広告内のプレースホルダ
  • ユーザの状況に応じてリアルタイムで広告の内容を差し替えることが可能
    • 何を検索しているか
    • どんなデバイスを使用しているか
    • いつ広告を見ているか

# 広告のオブジェクトはINMUTEDだから何かを変えるときに再入稿が必要。そして再審査が発生する。

広告カスタマイザを利用すると、広告内の内容を差し替えることが可能なので、上記問題を回避することも可能。

ex) チケットの残り枚数やキャンペーンの残り時間など

不動産の検索などで、GerLocationをたどり、Feedで広告文と着地URLなどを変更することが出来る?

→ キャンペーンを分割して、地域ターゲティングごとで分割するような手間を無くせる。

広告パラメータとの違い

広告パラメータの場合:広告1件に月、2つまでのキーワードレベルの数値を挿入可能

  • 高い柔軟性・数値だけでなく、テキストの挿入も可能
  • マルチレベル:キャンペーン、広告グループ、キーワードレベルで値の設定が可能(一致度が高いものが利用される)
  • コンテキストの認識:デバイス、日付、時間帯ごとに値の設定が可能
  • 特殊な情報表示:カウントダウン関数を使用すれば、特定のイベントまでの残り日数および時間を表示させることが可能
  • 詳細なレポート:インスタンス値ごとの情報を得ることが可能。

注意:広告パラメータは廃止され、広告カスタマイザに置き換わります。

広告カスタマイザの強み

  • 価格や在庫など動的な情報を広告に表示
  • より効率的に広告を管理
  • ユーザに合わせた広告
  • 見込み顧客の行動を促す

あたりの情報を提供することが出来る。

広告カスタマイザのセットアップ

  1. フィードのセットアップ
  2. FeedItemにデータを追加
  3. 広告をセットアップ

レポート

AD_CUSTOMIZERS_FEED_ITEM_REPORT

  • 広告カスタマイザで使用されたフィードアイテムの統計情報を提供します。
  • 統計情報はフィードアイテムレベルで集計。
  • 各フィードアイテムに付き1行。

制限・注意事項

  • 同じ広告グループ内に、基本となるテキスト広告が設定されていることが必要
    • これにより、プレースホルダの値を設定し忘れていても広告は表示
  • 文字数制限にご注意(自動挿入された後の文字長が通常制限内か)
  • 広告とFeedItemの両方が審査の対象
  • 1つの広告内で使用できるデータソースは1フィードのみ
  • アカウントごとのフィード制限は400,000

Q&A

・フィードアイテムごとのレポートはAPIサポートされているか?

→ AD_CUSTOMIZERS〜ですよ。

・リンク先URLは変えられないか? 今後対応予定はあるか?

→ 現状は変えられない。 改良版URLを使って対応することを一案。

・フィードアイテムは一括設定できるか。

→ アイテム受け付けのメソッドは配列受付なので一括設定できる。

・登録中のフィードアイテムの確認方法

→ APIとバルク

・在庫数量などはMerchantCenterの在庫数と連動するか

→現状は手作業で変更しなければならない。

・今後追加されるであろうコンテキストはあるか。

→ 場所。またリマーケティングリストなどが考えられる。

ExtensionSettingService

〜フィードをより使いやすく〜

フィードとは

広告内に動的なコンテンツの表示を可能にします。

  • サイトリンク
  • 電話番号
  • アプリリンク
  • レビュー
  • 住所
  • コールアウト
  • カスタマイザ

何故変更するのか

フィードの使用が大変手間だったから。
4つのAPIサービス

  1. Feed
  2. FeedMapping
  3. FeedItem
  4. [Customer/Campaign/AdGroup]Feed

マッチング関数やフィード属性のマッピングなどを理解している必要があった。

自由だったが、設定やマッピングが面倒。

過去の手順

  1. サイトリンクフィードを作成する
  2. フォードをキャンペーンに関連付ける

新たな手順

Extension Setting Servicesは既にある程度設定されたオブジェクトを作っている。
よってマッピングが不要になった。

  • 広告表示オプションごとの新しいクラス
    • [Sitelink/Call/App/Review/Callout]Feed
  • 関連付けるための新しいクラス
    • [Customer/Campaign/Adgroup]Extension]Setting
  • 管理するための新しいサービス
    • [Customer/Campaign/Adgroup]Extension]Services
  • マッチング関数は自動で生成される

すでに以前のやり方で実装している場合

  • AdWords UIで作成したフィードのFeedItemしか使用していないのであれば、移行の必要はなし。
  • FeedServiceを使用したカスタムフィードのFeedItemをしようしているのなら移行は必須ではないが推奨。

新しいものは簡単に実装が出来、内部実装的には過去の実装に翻訳されて実行されるので動かなくなるなどの影響はない。
シンプルな表記になっただけである。

# Java移行ユーティリティが近日中に提供される

制限事項

  • 住所表示オプションはまだサポートされていない
  • カスタムフィールドとマッチング関数はない
  • 広告表示オプションごとに使えるフィードは1つのみ
  • UIから作成する自動で生成されるフィードには origin=ADWORDSと設定されるので、スキーマの変更が出来ない
    • APIから作成するとorigin=USERとなるので変更できる

フィードが変更できなくて問題になるケースはほとんどないだろうが・・・。

改良版URL

改良版URL管理システムとは

背景

計測ツールのパラメタ情報が増加したことにより、URLの管理が複雑になりつつある。

目的

共有トラッキングテンプレートと新しいバリュートラックを活用することにより、キーワードと広告の設定・管理コストを削減する

審査対象となるURL量を減少し、審査スピードの迅速化を図る

何が変わるの?

今まで「最終リンク先URL&トラッキング」という形だったが、実際の「LPURL」と「トラッキング情報」を別の領域に設定する

そしてそのトラッキング情報を階層化出来る。(パラメタをアカウント・キャンペーン・広告グループに持たせることが出来るようになった)

LPのURLが同一であれば1回のみのクロールとなるので、クロール負荷と審査スピードが上がる。
その判別を行うため、LP URLを別で定義する。

また、トラッキングパラメータの変更では再審査などは発生しない。

メリット

  1. 共通パラメタは構造管理出来るため管理が容易に
  2. 広告審査が早く・少なくなる
  3. クラサバの負荷が減る
  4. 新しいValueTrackの活用が出来る

新しいValueTrackパラメータ一覧

  • campaignid -> キャンペーンID
  • adgroupid -> 広告グループID
  • targetid -> 広告が表示された全てのトリガー(キーワードやリマケリストなど)
  • loc_interest_ms -> 興味関心がある地域ID
  • loc_physical_ms -> 実際の地域ID
  • feeditemid -> FeedItemId
  • lpurl -> 最終ページURL

カスタムパラメータは任意に設定できる。アンダーバーで始まる必要がある。

  • _mykwid(例)

Adwordsから自動で割り当てられるIDを利用する場合はValueTrack。
自社で設定したい場合、カスタムパラメータを活用する

活用方法

福岡への航空券を「航空券 福岡」と検索した東京のユーザに対してのマーケティング

  1. interest_ms = 福岡のID
  2. physical_ms = 東京のID

となるため、LPで羽田→福岡への航空券をデフォルトで表示させることが出来る?

アップグレード方法

現状の運用方法によって異なる。

  • 基本的なアップグレード
  • 高度なアップグレード

がある。

基本的なアップグレード

横スライドして自動適用。審査がはいらない。

高度なアップグレード

新たな共通トラッキングテンプレートを利用。

再審査が入るが、U2を利用できるようになる。

移行時に審査や統計情報のリセットが行われないケース

  1. 既存URLと移行後URLが一致
  2. トラッキングテンプレートは同じ階層で設定
  3. 広告の編集画面ではなく、アップグレードツールを利用する

上記3点を満たしていれば、広告IDが変更されず、再審査や統計情報のリセットが行われない。

{lpurl}の特性

最終ページのURL。

  • 先頭に利用される場合、エンコードされない。
  • 文中に利用される場合、自動でエンコードされる。

リダイレクト型トラッキングURLを設定する際の注意点

  • 最終ページURLは広告表示URLドメインと一致していること
  • 最終ページURLはリダイレクト語の実際のLP URLと一致していること

という条件なので、サードパーティサーバからリダイレクトする場合、自動移行に任せてしまったら審査落ちをしてしまうので、マニュアルでアップデートしないといけない。

GAのパラメータを手動設定している方へ

自動設定しましょう。ミスもなくなりますし、楽になります。

クローラーがどれくらいきてるのか知りたい場合

UAはWebマスターツールに掲載している。「Ads bot」というUA。

これを拒否してしまうと、審査落ちするのでやめて下さい(汗

最終ページURLフィールドについて

ユーザーが広告をクリックした後、ブラウザに表示されうる「全てのURL

A/Bテストなどをし、着地URLを変えている場合は全てのURLを指定する必要がある

ほとんどは普通に一つのURLでok。

Q&A

いろいろとありましたが、大半はfinalURLの使用によるもの。

・A/Bテストでリダイレクトする場合、finalURLに全て記載しなければならない。ということでしたが、削除する場合も再審査が走るか。
→ 再審査の必要がある。

・GAのウェブテストを活用していても広告の再審査が必要になるか。
→ 仕様上、現状必要となる。

・自動マイグレートが走った際、動いていないアカウントが多く管理していると審査落ちが大量発生するかと思います。その影響でMCCアカウントの停止などの可能性があるか。
→ 現状回答できない。エスカレーションします。。

・301転送や302転送、headのメタリフレッシュの活用など、さまざまな転送があるが、それぞれ最終URLは何になるか。
→ 302が理想。 301は適切ではない。 メタリフレッシュはJSを理解しないクローラーが多いため可能な限りサーバで。

基本的に広告クリックで訪問するLPはすべてfinalURLに記載しないといけない。
# finalURLの複数指定はセミコロンで区切って入力する。

効果的なレポート

レポートのコンセプト

レポートとは

PDCAサイクルを回すための欠かせない要素。

これからレポートを始める方へ

いろいろと細かいこと書いてあるのでぜひドキュメント読んでね。

レポートのヒント

単一アトリビューション レポート

  1. Criteria Performance Report

複数アトリビューションレポート

  1. Display KeywrodsPerformance Report
  2. PlacementPerformance Report
  3. Display TopicPerformance Report

ディスプレイの場合「複数アトリビューション」となる。

複数の条件検索

  • 年齢
  • トピック
  • キーワード

でターゲットを設定した場合、

単一アトリビューションの場合

どこか一つのクライテリアに記録される。
優先度が高い一つにしかつかないためUIと一致しない。

→ ベストソリューション:複数アトリビューションを利用する。

  • 年齢別レポート
  • トピック別レポート
  • キーワードレポート

それぞれを取得する。

UIとAPIで得られる数値は異なる。

更新時間がキャンペーンやアカウントなどレベルごとで異なる。
1日後に更新。というものに関して、「1日」という基準がGoogle本社のあるMountain Viewのタイムスタンプ基準になるため、かなり反映時間がずれることがある。

ゼロインプレッションのレポート

一度も表示がなかったものは標準の問い合わせではレコード自体が返ってこない。

と設定することで取得できる。

どういう時に使うか?

すべてのキャンペーン一覧などを取得する時はこの方法を利用する(早い)

# 分割(セグメント)を行うとゼロインプレッションのレコードは取得できなくなる。

分割(セグメント)

  • Selectorのfieldsに追加するとセグメント分け出来る。
    • 分割し過ぎるとわけわからなくなるので、少しずつ試す必要がある。
  • レコード返却条件として、Metrics(ClickやImpressionなど、取得するデータ)を指定する必要がある。

特別なキーワードID

ディスプレイのキーワードなどで活用される。
ID:3000000, Value:Content という固定値でまとめられる。

レポートの分類

Display用のレポート

  • 複数アトリビューションレポート
  • 単一アトリビューションレポート

構成レポート

  • ACCOUNT_PERFORMANCE_REPORT
  • CAMPAIGN_PERFORMANCE_REPORT
  • ADGROUP_PERFORMANCE_REPORT
  • AD_PERFORMANCE_REPORT
  • KEYWORDS_PERFORMANCE_REPORT
  • URL_PERFORMANCE_REPORT

詳細レポート

  • GEO_PERFORMANCE_REPORT
  • DESTINATION_URL_REPORT
  • CREATIVE_CONVERSION_REPORT
  • SEARCH_QUERY_PERFORMANCE_REPORT
  • CALL_METRICS_CALL_DETAILS_REPORT

設定用レポート

  • CAMPAIGN_LOCATION_TARGET_REPORT
  • CAMPAIGN_AD_SCHEDULE_TARGET_REPORT
  • CAMPAIGN_PLATFORM_TARGET_REPORT

広告表示オプションレポート

  • PLACEHOLDER_REPORT

動的検索系レポート

  • KEYWORDLESS_***

共有レポート

  • SHARED_***

レポートはSOAPリクエストでも取得できるが、サイズに上限(100000レコードまで)があるため、取得できないことがある。

有用な例

AwReporting

ローカルのDBにレポートをダウンロードできるツール。
ローカルアプリを作るベストソリューションの一つ。

参考リンク

Adwords API リリースノート

Aw Reporting

個人的まとめ

これから益々広告というものは高度化する。
「面から人へ」と言われ続けているが、人という粒度が1個人までに降りて来る日も遠くないだろう。
そうなると、DSPはファーストパーティ、サードパーティ問わずCookieを活用したDMPと化すだろうし、マルチデバイスの分析も現在以上にはるかに高度化するだろう。

社会がそのように変化したタイミングで「入札を行う」「入稿のCSVを作る」などの作業をしているようでは置いて行かれることは必至だろう。

テクノロジーが正しい方向に成長し、人が正しい方向でリソースを活用できれば広告はより良い物になるのではないだろうか。

P.S.
YahooさんがんばってGoogleさんについていって下さい(ニッコリ
Googleだけ自動化出来ても現場の工数はそこまで減らないので…。

あとかなり走り書きなので誤字・脱字はご容赦ください。。。

スポンサーリンク

参考になればシェアしてもらえるとうれしいです

  • このエントリーをはてなブックマークに追加

フォローする

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です