...
この記事は Andrew Burke による Google Ads Developer Blog の記事 "Feed-based Extensions Sunset in Google Ads APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google 広告は最近、アセットベースの拡張機能(表示オプション)を導入しました。この新しいパラダイムは、既存のフィードベースの拡張機能と比べて、拡張機能の管理の複雑さが軽減されます。アセットベースの拡張機能は、Google Ads API でのみサポートされます。

アセットベースの拡張機能は、現在のフィードベースの拡張機能に置き換わります。既存のフィードベースの拡張機能は、2 回にわけてすべて自動的に移行されます。住所表示オプション、ダイナミック広告、ページフィードなど、フィードを使うその他のサービスについては、後日あらためてお知らせします。

拡張機能の
タイプ
テスト
アカウントで
利用できる
アセット
本番
アカウントで
利用できる
アセット
自動
移行の
日付
フィードの
提供終了の
日付
リードフォーム Google Ads API v6 Google Ads API v6 2021 年 
10 月 20 日 
2022 年
2 月 15 日
プロモーション Google Ads API v7 Google Ads API v7 2021 年
10 月 20 日
2022 年
2 月 15 日
コールアウト
サイトリンク
構造化スニペット
Google Ads API v7 Google Ads API v8
2021 年
10 月 20 日
2022 年
2 月 15 日
アプリリンク
電話番号
ホテル コールアウト
画像
価格
Google Ads API v9
(仮)
Google Ads API v9
(仮)
2022 年
2 月 15 日
2022 年
4 月 8 日


何をする必要がありますか?
フィードベースの拡張機能とそれに関連するコードで、今後もアセットベースの拡張機能で利用したいものは、すべて可能な限り早急に移行する必要があります。 移行後は、フィードベースの拡張機能を削除してください。ある拡張機能のタイプに対して、フィードベースの拡張機能の代わりに任意のアセットベースの拡張機能を利用できます。詳しくは、拡張機能の移行ガイドをご覧ください。現在使用できるすべてのアセットのタイプにアクセスできるように、テスト アカウントを使ってアセットベースの拡張機能の実装を開発し、テストすることを検討しましょう。

自動移行日以降は、AdWords API と Google Ads API でフィードベースの拡張機能の作成や変更はできなくなります。フィードベースの拡張機能は、新しいデータを生成しなくなります。フィードに関連するレポートのクエリは 2022 年 8 月まで発行できます。その後は、すべてのフィードベースの拡張機能のデータは削除され、レポートのクエリはエラーを返すようになります。

10 月に間に合わない場合はどうなりますか?
個々のアカウントを 10 月の自動移行の対象からオプトアウトするようリクエストできます。具体的な方法は今後のブログ投稿でご案内します。オプトアウトする場合でも、初回移行分のフィードベースの拡張機能は、2022 年 2 月にすべてのアカウントで利用できなくなる点にご注意ください。


質問や懸念事項、フィードバックがある方は、フォーラムからご連絡ください。


...
この記事は Thanet Knack Praneenararat による Google Ads Developer Blog の記事 "Google Ads API v4 and v5 sunset reminder" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Ads API v4 と v5 は、2021 年 6 月 23 日に提供を終了します。それ以降、v4 と v5 API へのすべてのリクエストは失敗します。API アクセスに影響がないように、必ず 2021 年 6 月 23 日までに新バージョンに移行してください。

移行に役立つさまざまなリソースを準備しています。 アップグレードの際に疑問に思うことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


Google Play は、ゲーム業界で働く女性のサポートをしたいと考えています。そこで、2021 年 7 月 2 日に ゲーム業界で働く女性を対象に「自分が変われば周りも変わる」をテーマにしたオンライン イベント Women in Gaming 2021 を開催します。

第 2 回目となる今回のイベントは、二部構成で開催します。第 1 部では、ゲーム業界、IT 業界の第一線で活躍されている女性リーダーをお招きし、ゲーム業界での働き方や新しいゲーム市場への考察を深めるパネル トークや質疑応答、第 2 部では、Google のグローバルでの取り組みの一環である「#IamRemarkable」プログラムとのコラボレーションにより、さらにインタラクティブなワークショップを行う予定です。

Women in Gaming とは?

性別に左右されずゲーム業界で女性が活躍できる環境を作りを目指して、Google Play が主催で不定期に開催しているイベントです。ゲーム業界での働き方や新しいゲーム市場への考察を深めるほか、Google の担当者からは Google の多様性を高める活動について、また、誰もが活躍できる社会を目指す取り組みについてお話しします。

#IamRemarkable とは?

2 人の Google 社員、Anna Vainer と Anna Zapesochini によって立ち上げられたワークショップを中心としたプログラムです。当初は女性に特化した取り組みで、女性が自分の仕事の実績をオープンに話せるように後押しをする目的でスタートしました。しかしながら、こういった問題に直面しているのは女性に限らないことに着目し、女性以外でも、あらゆる過小評価されているグループ属する人々が、職場をはじめとするあらゆる場所での自分の実績をオープンに語り、「謙虚であるべき」という社会的通念やガラスの天井を打ち破れるようにサポートすることを目指しています。

開催概要

イベント名 : Women in Gaming 2021
開催日時 : 2021 年 7 月 2 日 10 時 00 分  - 12 時 30 分
開催形式 : オンライン ウェビナー
対象 : ゲーム業界、または関連業界で業務をする女性、または興味のある女性 。なお、男性の参加も歓迎です

※開始 10 分前から入場可能です

タイムテーブル

  • 10:00〜10:05 オープニングのご挨拶 : (Google Play Partnerships ゲーム部門 マネージャー  河田 瑠衣)

  • 10:05 〜 10:35 第 1 部 - パネルトーク :(株式会社 ミクシィ 執行役員モンスト事業本部長 根本悠子、株式会社 スクウェア・エニックス・ホールディングス広報室長 野原 和歌)
    [モデレーター] Director,  Apps, Commerce and Entertainment, Google 藤木 貴子

    ゲーム業界、IT 業界の第一線で活躍されている女性リーダーをお招きし、男性社員の割合が多い業界で、女性としてどのようにポジションを確立し、また、自身の働き方や考え方が変わったことで、周りへポジティブな影響を与え、企業全体をどのように活性化されてきたのか。そのご経験をディスカッション形式でお話しいただきます。

    ※参加人数に制限を設けておりませんので、お誘い合わせの上ご参加ください。

  • 10:35〜10:50  Q&A : (株式会社 ミクシィ 執行役員モンスト事業本部長 根本悠子、株式会社 スクウェア・エニックス・ホールディングス広報室長 野原 和歌、Director,  Apps, Commerce and Entertainment, Google  藤木 貴子)
    [モデレーター] Google Play Partnerships ゲーム部門 マネージャー  河田 瑠衣

    イベント中にツールへ寄せられた質問へご回答します。

  • 10:50〜11:00 Break - 休憩

  • 11:00〜12:30 第 2 部 - #IamRemarkable ワークショップ : (Google Android Partner Enablement Manager, APAC, #IamRemarkable 日本責任者 五木田 菜津紀)


    Google がグローバル規模で力を入れている取り組みである「#IamRemarkable」(※)プログラムとのコラボレーションにより、さらにインタラクティブなグループワークショップを行います。このワークショップでは現代社会における多様性がいかに重要であるかを理解し、自己肯定感を低くし、自分の成果を共有することを阻んでしまっているものは何なのかを考え、改めて自身を見つめ直すためのワークショップです。

    こちらは、Google Meet を活用したセッションになります。参加者数に限りがございますので、視聴登録フォームより事前にお申し込みください。

※登壇者、内容は変更される場合がありますので、最新情報は Web サイトでご確認ください

参加方法

こちらのイベントページよりご登録ください。第 1 部への参加は、当日でも可能です。第 2 部の「#IamRemarkable」ワークショップは、参加者数に制限を設けております。先着順となりますので、必ず事前にご登録ください。


Posted by Rui Kawada - Google Play Partnerships, Games

...
この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 4 - Creating the Resource Service" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 3 では、GoogleAdsFieldService を使って詳細な JSON リソース スキーマを作成する方法について説明しました。これが、Angular アプリケーションで使う正規データセットとなります。パート 4 では、アプリケーションのさまざまな部分でどのフィールドがユーザーに表示されるかを決めるリソース サービスを作成する方法について説明します。

背景

新しいインタラクティブ Google 広告クエリビルダーのメリットの 1 つは、ユーザーの選択内容に応じてフィールドが動的に更新され、フィールドが選択できるかどうかが表示されることです。選択できない場合は、なぜそのフィールドが選択できないかがわかるフィードバックがユーザーに返されます。これを実現するには、Google Ads Query Language(GAQL)文字列の FROM 句のメインリソースに基づいて、その GAQL 文字列のそれぞれの句で選択できるフィールドのリストを提示する必要があります。そのロジックを含む、ResourceService という名前のサービスを作成します。すると、Angular のサービスと依存関係の注入モデルを使って適切なフィールドと関連情報を取得し、任意のコンポーネントに設定できるようになります。

目的

このアプリは、FROM リソースがユーザーの現在の URL によって決まるように設計されています。そのため、FROM 句のリソースとすべての利用可能なフィールドのリストは、その URL によって決まる定数となります。この投稿では、SELECTWHEREORDER BY という 3 つの GAQL 句のみについて考えることにします。動的にフィールドを設定できる句はこれだけだからです。LIMIT は整数のみを受け付け、PARAMETERS には 1 つの選択肢しかありません。


ユーザー エクスペリエンスを向上するため、それぞれの句では、利用可能なフィールドを属性フィールド指標セグメント属性付きリソース フィールドの 4 つのカテゴリに分類します。ここでの目的は、指定された句とカテゴリに応じて、関連フィールドを提供する ResourceService を作成することです。

実装

前回生成したリソース スキーマを活用すると、URL によって決まる FROM 句のメインリソースに対するエントリを選択し、フィールドのサブエントリを絞り込んで、特定の条件に一致する fields だけを提供できます。


まずは、句によってフィールドを分類するところから始めます。
  • SELECT 句のフィールドは、selectable プロパティが true に等しい
  • WHERE 句のフィールドは、filterable プロパティが true に等しい
  • ORDER BY 句のフィールドは、sortable プロパティが true に等しい
このフィールド リストは、さらに属性フィールド、指標、セグメント、属性付きリソース フィールドに分類できます。指定された句から指標とセグメントを取得するのは簡単です。リソース スキーマには指標とセグメント(セグメント化リソースを含む)のリストが含まれているからです。それぞれの句について、句に関連する前述の条件を満たすすべてのセグメントと指標を含めます。

同じように、FROM 句のリソースの attributes を調べ、リソース名で始まり、その後にドットが存在するものを絞り込み、句に関連する前述の絞り込み条件を適用することで、それぞれの句のメイン属性フィールドを取得できます。

attributes エントリのその他のフィールドは、すべて属性付きリソース フィールドです。属性付きリソースのリストは、メインリソースを除くリソースの attributes の一意なプレフィックス(ドットの前のテキスト)を集めることで生成できます。最後に、それぞれの属性付きリソースの名前がプレフィックスになっているフィールドを選択すると、それぞれの属性付きリソースについて、句ごとのフィールド リストを作成できます。

以上のロジックがすべてそろえば、インターフェースを作成し、指定されたカテゴリと句に応じてフィールドのリストを返すメソッドを公開できます。すると、ResourceService に注入される任意のコンポーネントは、対応するメソッドを呼び出すだけで、適切なフィールドのリストを取得できるようになります。

まとめ

以上で、アプリで表示している句とカテゴリに基づいて GAQL クエリを作成しているユーザーに、関連フィールドを表示する ResourceService を作成できました。今回の投稿では、以下について説明しました。

Google Ads API での GAOL クエリの構築について理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。




この記事は Google Pay、デベロッパー アドボケート、Soc Sieng による Google Developers Blog の記事 "Updated Google Pay button increases click-through rates" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Pay ヘッダー

Google Pay ボタンが改善され、クリックスルー率とご購入手続きのエクスペリエンスの向上にすばらしい効果を発揮しています。

アップデートされた Google Pay ボタンには、ユーザーのカード情報が表示されます。これにより、ユーザーがボタンを使う確率が 30%、コンバージョン率が 3.6% 上昇します。

カードの種類と下 4 桁を表示することで、ユーザーは支払いに使うカード情報が Google アカウントに保存済みであることを認識し、Google Pay が提供する素早く簡単な購入手続きを選ぶ可能性が高まります。

動作の仕組み

ユーザーが購入するときに、Google アカウントに有効な支払い方法が設定済みであれば、Google Pay ボタンに最後に使ったカードの種類と下 4 桁が表示されます。

動的な Google Pay ボタン

図 1. 追加情報を含む Google Pay ボタンの例

Google Pay ボタンで支払う

図 2. 追加情報を含まない Google Pay ボタンの例

カード情報を表示する方法

デフォルトのボタン オプションで createButton API を使うと、Google Pay ボタンが自動的にアップデートされ、ユーザーのカード ネットワークと下 4 桁が表示されるようになります。

createButton API をカスタマイズして buttonTypeplain または short に設定していた場合は、buy に設定すると、Google Pay ボタンにユーザーのカード情報が表示されます。

まだ createButton API を組み込んでいない方は、クリックすれば支払いの詳細が開くことをユーザーが認識できるように、今すぐ組み込むことをご検討ください。

実例

Google Pay ボタンをその他のボタン オプションで試すには、こちらのボタン カスタマイズ ツールをご確認ください。

次のステップ

Google Pay を始めるには、Google Pay の Business Console にアクセスします。新機能を使うには、createButton API を利用する必要があります。ご質問があれば、Twitter で #AskGooglePayDevs を使って @GooglePayDevs にツイートしてください。



Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "The Query Builder Blog Series: Part 3 - Creating a Resource Schema" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダーの構築過程についてお伝えしています。シリーズのパート 2 では、インタラクティブ クエリビルダー Angular アプリケーションの正規データセットとして利用する詳細な JSON リソース スキーマの設計について説明しました。パート 3 では、GoogleAdsFieldService を使ってそのスキーマを作成する方法を取り上げます。

データの取得

パート 2 で説明したスキーマのデータの大半は、次のクエリを使って GoogleAdsFieldService という API を呼び出すことで作成します。

SELECT name, category, data_type, selectable, filterable, sortable, selectable_with, metrics, segments, is_repeated, type_url, enum_values, attribute_resources

結果は、Google Ads API で利用できるすべてのフィールドについての JSON オブジェクトの配列です。配列の各オブジェクトには、先ほどの SELECT 句のフィールドが含まれています。たとえば、ad_group のリスト項目は次のようになります。

{
"resourceName": "googleAdsFields/ad_group",
"name": "ad_group",
"category": "RESOURCE",
"dataType": "MESSAGE",
"selectable": false,
"filterable": false,
"sortable": false,
"selectableWith": [...],
"metrics": [...],
"segments": [...],
"isRepeated": false,
"typeUrl": "com.google.ads.googleads.v6.resources.AdGroup",
"enumValues": [],
"attributeResources": [...]
}


これをキーと値のペアに変換します。キーをエンティティ名、値をエンティティのメタデータにして、エンティティからメタデータを簡単に検索できるようにします。たとえば、ad_group エントリは次のようになります。

{
"ad_group": {
"resourceName": "googleAdsFields/ad_group",
"name": "ad_group",
"category": "RESOURCE",
"dataType": "MESSAGE",
"selectable": false,
"filterable": false,
"sortable": false,
"selectableWith": [...],
"metrics": [...],
"segments": [...],
"isRepeated": false,
"typeUrl": "com.google.ads.googleads.v6.resources.AdGroup",
"enumValues": [],
"attributeResources": [...]
}


パート 2 で設計したスキーマと比べると、変換したオブジェクトにはいくつかのフィールドが存在しないことがわかります。そこで、属性、フィールド、説明、表示名を表すセクションを追加します。

属性

スキーマの設計を思い出してみると、それぞれのリソースに attributes という名前の配列があり、そのリソース自体と任意の属性付きリソースに存在するすべてのフィールド名が含まれていました。この配列は、GoogleAdsFieldService クエリの結果を反復処理し、そのリソースかいずれかの属性付きリソースで始まるエントリ名にドットを追加することで作成できます。

フィールド

このスキーマの fields エントリは、(a)先ほど作成した属性配列の項目、(b)リソースの指標、(c)リソースのセグメントのそれぞれがエントリとなるオブジェクトです。各エントリの値は、先ほど作成したオブジェクトのそれぞれのフィールドの値となります。ただし、各フィールドに incompatible_fields 配列を追加する必要があります。

fields オブジェクトの各エントリの incompatible_fields 配列を作成するには、トップレベル オブジェクトに存在するフィールド、指標、セグメントのそれぞれが、評価対象のフィールドの selectable_with と一致するかどうかを確認します。一致しない場合、そのフィールド、指標、セグメントを incompatible_fields 配列に追加します。

説明

次に、トップレベルのリソースと fields エントリ内の項目のそれぞれに説明を追加します。ここで重要なのは、トップレベルのリソースによって、フィールドの説明が異なる場合があることです。たとえば、ad_group.id の説明には「出力のみ。広告グループの ID。」とありますが、campaign.id の説明には「出力のみ。キャンペーンの ID。」とあります。REST ディスカバリー ドキュメントには、ネストした説明が含まれています。これは正規の説明オブジェクトを作るために利用できるので、これを使ってスキーマを設定します。このステップには解析とフォーマット設定が必要ですが、詳細は割愛します。必要になったときのために、REST ディスカバリー ドキュメントが用意されていることを覚えておいてください。今のところ、この方法が利用できる最適なソリューションですが、GoogleAdsFieldService から説明が返されるようになれば、そちらを使う方が簡単でしょう。

表示名

残る作業は、リソース スキーマの表示名フィールドの設定です。この作業は単純で、名前に含まれるアンダースコアをスペースで置換し、各単語の最初の文字を大文字にするだけです。

リソースのフィルタリング

これで、リソース スキーマの内容をすべて設定できました。ただし、これには GoogleAdsFieldService クエリが返したすべてのリソース、フィールド、セグメント、指標が含まれています。このスキーマをフィルタリングし、categoryRESOURCE である項目のみを含むようにします。

まとめ

詳細なフィールド情報と、それぞれのフィールドと同時に選択できないフィールドのリストを含む、拡張リソース スキーマが作成できました。Angular アプリケーションでは、このスキーマを利用します。今回の投稿では、以下について説明しました。
  • GoogleAdsFieldService を使ってフィールドのメタデータを取得する方法
  • GAQL でのフィールドの同時使用可否
  • REST ディスカバリー API
Google Ads API でできることについての理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


Chrome に関する公式の開発者向け情報を発信しています。英語になりますが、同じ内容は翻訳して からも日本語で発信しています。 標準化を前提としたウェブ API を中心に、Chrome に限定されないウェブ開発のベストプラクティスを紹介しています。現在英語が中心ですが、ローカライズできるよう開発を進めています。
Google の Chrome / Developer Relations チームでは、内容によって様々なチャネルから情報発信を行っています。ウェブ開発者の皆さんに少しでもお役に立つよう、Google 公式のウェブ開発者向けリソースをまとめました。

Chromium Blog

Chrome に関する公式の開発者向け情報を発信しています。英語になりますが、同じ内容は翻訳して Google Developers Japan Blog からも日本語で発信しています。

web.dev

標準化を前提としたウェブ API を中心に、Chrome に限定されないウェブ開発のベストプラクティスを紹介しています。現在英語が中心ですが、ローカライズできるよう開発を進めています。
  • web.dev/blog: ブログ形式で最新情報を発信しています。
  • web.dev/newsletter: 購読することでメールで最新情報をお届けします。(現在英語のみ)

Chrome Developers

Chrome DevTools や Extension など、Chrome 独自機能の解説や API リファレンスを掲載しています。

Google Chrome Developers - YouTube channel

Chrome チームによる開発者向け情報の動画配信。API の使い方解説やイベントの映像配信など。

Chrome Status

API の開発状況、チャネルごとのリリース時期、機能の使用状況統計情報など、Chrome の開発状況を確認することができます。

Chromium Bug Tracker

Chromium のバグトラッカー。Chrome でバグを見つけた場合はこちらからレポートしてください。

Twitter

公式
  • @ChromiumDev: Chrome Developers - Chrome 関連の開発者向け情報を主に英語で発信
  • @googledevjp: Google Devs Japan - Chrome に限らない Google の開発者向け情報を日本語で発信
社員個人アカウント
  • @agektmr: Eiji Kitamura / えーじ - Developer Advocate
  • @sisidovski: Shunya Shishido - Web Ecosystem Consultant
  • @uskay: Yusuke Utsunomiya - Web Ecosystem Consultant
  • @chikoski: chikoski - Developer Advocate
  • @piropiroanna: きらきら☆あんなたん - Web Ecosystem Consultant
  • @KenjiBaheux: Kenji Baheux - Chrome Product Manager