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

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	Reception	Coffee and cookie
13:30:00	Talks	Introduction
13:45:00	Talks	Keynote
14:00:00	Talks	Keynote
14:15:00	Talks	How AdWords maps into AdWords API
14:30:00	Talks	How AdWords maps into AdWords API
14:45:00	Talks	Ad Customizers
15:00:00	Talks	Ad Customizers
15:15:00	Break	–
15:30:00	Talks	Hard Feed Types or AdWords API and the mobile world
15:45:00		Hard Feed Types or AdWords API and the mobile world
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		Effective Reporting
17:45:00	Ending	Q&A

イントロダクション

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

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

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

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

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

＃正直、そんな話は無かったｗ

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 ｃriteriaフィールドは返り値が整数に（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種のサービス

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

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

基本的な流れ

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

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

広告表示オプション

広告表示オプションは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シェルとかでも取れるｗ

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

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

雑談

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

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

広告カスタマイザ

広告カスタマイザとは

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

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

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

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

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

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

広告パラメータとの違い

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

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

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

広告カスタマイザの強み

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

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

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

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

レポート

AD_CUSTOMIZERS_FEED_ITEM_REPORT

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

制限・注意事項

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

Q&A

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

→ AD_CUSTOMIZERS〜ですよ。

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

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

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

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

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

→ APIとバルク

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

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

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

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

ExtensionSettingService

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

フィードとは

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

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

何故変更するのか

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

Feed
FeedMapping
FeedItem
[Customer/Campaign/AdGroup]Feed

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

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

過去の手順

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

新たな手順

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を別で定義する。

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

メリット

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

新しいValueTrackパラメータ一覧

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

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

_mykwid（例）

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

活用方法

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

interest_ms = 福岡のID
physical_ms = 東京のID

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

アップグレード方法

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

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

がある。

基本的なアップグレード

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

高度なアップグレード

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

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

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

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

上記３点を満たしていれば、広告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サイクルを回すための欠かせない要素。

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

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

レポートのヒント

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

Criteria Performance Report

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

Display KeywrodsPerformance Report
PlacementPerformance Report
Display TopicPerformance Report

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

複数の条件検索

年齢
トピック
キーワード

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

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

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

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

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

それぞれを取得する。

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

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

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

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

includeZeroImpressions = true

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

どういう時に使うか？

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

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

分割（セグメント）

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だけ自動化出来ても現場の工数はそこまで減らないので…。

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

Adwords API Workshopsとは

タイムテーブル

イントロダクション

KeyNote

新機能

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

共有設定が復活

Extension Setting Services

改良版URL

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

アプリディープリンク

新しいレポート

レポート

予定されている廃止機能

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

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

広告表示オプション

ExternalRemarketingUserListは廃止

FeedItemService

Geo ｃriteriaフィールドは返り値が整数に（Stringだった

Adwords UIとAPI

AdWords APIについて

認証

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

Adwordsオブジェクト

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

基本的な流れ

広告表示オプション

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

Adwordsダッシュボード

UI

API

レポートタイプ

その他

雑談

広告カスタマイザ

広告カスタマイザとは

広告パラメータとの違い

広告カスタマイザの強み

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

レポート

制限・注意事項

Q&A

ExtensionSettingService

フィードとは

何故変更するのか

過去の手順

新たな手順

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

制限事項

改良版URL

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

背景

目的

何が変わるの？

メリット

新しいValueTrackパラメータ一覧

活用方法

アップグレード方法

基本的なアップグレード

高度なアップグレード

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

{lpurl}の特性

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

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

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

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

Q&A

効果的なレポート

レポートのコンセプト

レポートとは

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

レポートのヒント

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

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

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

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

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

分割（セグメント）

特別なキーワードID

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