ブラウザが（HTTP でなく）HTTPS でウェブサイトに接続すると、ネットワーク上の盗聴者や攻撃者は、その接続で共有されるデータ（個人情報やそのページ自体など）を傍受したり改変したりできなくなります。ウェブのエコシステムにとって、このレベルのプライバシーとセキュリティは不可欠です。そのため、Chrome では HTTPS のサポートを広げるための ...
この記事は Google Chrome チーム、Shweta Panditrao、Devon O'Brien、Emily Stark による Chromium Blog の記事 "Increasing HTTPS adoption" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ブラウザが（HTTP でなく）HTTPS でウェブサイトに接続すると、ネットワーク上の盗聴者や攻撃者は、その接続で共有されるデータ（個人情報やそのページ自体など）を傍受したり改変したりできなくなります。ウェブのエコシステムにとって、このレベルのプライバシーとセキュリティは不可欠です。そのため、Chrome では HTTPS のサポートを広げるための取り組みを継続しています。
ありがたいことに、HTTPS の採用はここ数年で大幅に増加しています。また、ほとんどのオペレーティング システムで、Chrome が読み込むページの 90% 以上が HTTPS になっています。しかし、HTTPS をウェブの優先プロトコルにし、HTTPS をサポートしていない残りのウェブでユーザーの保護を強化するために、まだできることがあります。そこで今回は、この領域での今後の作業についてお知らせします。

HTTPS ファーストの世界をオプトインする

M94 以降の Chrome は HTTPS ファースト モードを提供します。このモードでは、すべてのページ読み込みが HTTPS にアップグレードされ、HTTPS をサポートしないサイトを読み込む際には、ページ全体に警告が表示されます。このモードを有効にすると、可能な場合には常に HTTPS でサイトに接続し、HTTP でサイトに接続する前には警告が表示されることが保証されます。エコシステムからのフィードバックに基づき、将来的には、すべてのユーザーで HTTPS ファースト モードをデフォルトにする予定です。Mozilla も、将来的に Firefox のウェブ ブラウジングを HTTPS 専用モードにする予定であることを発表しました。

鍵アイコンの実験

HTTPS ファーストの未来に向かうにあたり、ブラウザがサイトを HTTPS で読み込んでいることを示すために使われることが多い鍵アイコンの再検討も行っています。とりわけ、Google の調査によると、実際に安全なのは接続のみであるにもかかわらず、ユーザーはこのアイコンを信頼できるサイトとみなすことがわかっています。最近の調査では、鍵アイコンの意味を正しく認識できたのは、回答者の 11% だけでした。Chrome の M93 では、この混乱を減らすための試みとして、アドレスバーの鍵アイコンをこれまでよりも中立的なページ情報の入口に置き換える実験をする予定です（下の例を参照）。この実験により、重要なプライバシーとセキュリティの情報や、ページ情報で提供されるコントロール（サイトのパーミッションなど）が見つけやすくなることを期待しています。重要なのは、HTTPS がサポートされていないサイトで「保護されていない通信」のインジケーターが表示される点は変わらないことです。また、この実験には、オプトアウトを希望する組織のためのエンタープライズ ポリシーも含まれています。いずれの場合も、全面的にリリースを行う場合は、事前にお知らせします。


HTTP ウェブのユーザーを保護する

今後のバージョンの Chrome でユーザーが HTTPS ファースト モードを採用することを楽しみにしていますが、その一方で、Chrome の HTTP 接続のサポートを継続し、安全でない接続を使用しているときに常にユーザーを保護して通知をするための追加策を実施します。新機能を安全なオリジンに限る、安全でないオリジンで充実した機能を使えなくするといったこれまでの取り組みの続きとして、ウェブ プラットフォームのさまざまな機能を評価して HTTP ウェブページで制限すべきかどうかを判断する作業に着手する予定です。

ユーザーに最大限のセキュリティ強化を提供する変更に注力できるように、この領域で今後優先する作業は、以下の原則に従って判断します。
  • 安全でない接続を利用するサイトを、信頼するかどうか判断する際の情報提供を強化する
  • 安全でない接続では、サイトでセキュリティ ポリシーをオプトアウトできないように制限する
  • 安全でない接続で提供されたサイトのコンテンツを Chrome が保存する方法や期間を制限する
この原則に基づく行動予定の詳しい説明や、影響を受ける機能リストの改訂版は、Chromium Wiki で管理されています。また、今年中にさらに詳しい情報をお伝えする予定です。

Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Google Open Source Security チーム、Kim Lewandowski、Azeem Shaikh、Laurent Simon による Google Online Security Blog の記事 "Measuring Security Risks in Open Source Software: Scorecards Launches V2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 オープンソース プロジェクトの「リスクスコア」を生成する自動セキュリティ ツール、Scorecards プロジェクトの貢献者の皆さんは、昨秋のリリース以降、たくさんのことを成し遂げています。この度は、Open Source Security Foundation コミュニティとともに、Scorecards v2 についてお知らせします。新しいセキュリティ チェックを追加して評価対象のプロジェクト数を拡大し、そのデータを簡単に分析できるようにしています。

現在、多くのソフトウェアがオープンソース プロジェクトを利用しています。そのため、依存関係が安全かどうかを簡単に判断する方法が必要です。Scorecards は、プロジェクトのサプライ チェーンを管理する際に、変化を続けるパッケージを継続的に評価するために必要な煩雑さや手作業を軽減するために役立ちます。ユーザーは、依存関係がもたらすリスクを自動的に評価し、そのデータを使って情報に基づいてリスクを受け入れるかどうかを判断したり、代替のソリューションを評価したり、メンテナンス担当者と協力して改善したりできます。

リスクの特定

昨秋より、Scorecards のカバレッジは拡大しています。Google が今年提唱した Know、Prevent、Fix フレームワークに従って優先順位付けをし、いくつかの新しいチェックを追加しました。

悪意のある貢献者

悪意のある貢献者や侵害されたアカウントによって、コードに潜在的なバックドアが紛れ込む可能性があります。こうした攻撃は、コードレビューによって軽減できます。新しい Branch-Protection チェックを使うと、プロジェクトでコードをコミットする前に別のデベロッパーによるコードレビューを必須にすることができます。GitHub API の制限のため、現在、このチェックはリポジトリ管理者のみが実行できます。サードパーティ リポジトリの場合は、これよりも情報が少ない Code-Review チェックを代わりに利用できます。

脆弱なコード

デベロッパーやピアレビューの最大限の努力にもかかわらず、脆弱なコードがソース コントロールに紛れ込み、検出されないままになることがあります。そのため、継続的にファジングや静的コード解析をし、開発ライフサイクルの早い段階でバグを発見できることが重要です。そこで、CI/CD システムの一部として、プロジェクトがファジングや SAST ツールを使っているかどうかを検出するチェックを追加しました。

ビルドシステムの侵害

GitHub プロジェクトで一般的に使われる CI/CD ソリューションは、GitHub Actions です。このアクション ワークフローの危険なところは、信頼できないユーザー入力を扱ってしまう可能性があることです。つまり、攻撃者は悪意のある pull リクエストを作成することで、特権 GitHub トークンにアクセスし、それを使ってレビューを経ずに悪意のあるコードをリポジトリにプッシュすることができます。Scorecard の Token-Permissions 防止チェックは、このリスクを緩和するため、GitHub トークンをデフォルトで読み取り専用にし、GitHub ワークフローが最小権限の原則に従っていることを検証します。

悪質な依存関係

どんなソフトウェアでも、依存関係が弱いほど安全です。これは当たり前に思えるかもしれませんが、依存関係を知るための第一歩は、依存関係を宣言し、その依存関係にも依存性を宣言させることです。この起源情報があれば、ソフトウェアのリスクを評価し、そのリスクを低減できます。残念ながら、よく目にするアンチパターンがいくつかあり、それによってこの起源の原則が崩れています。1 つ目のアンチパターンは、バイナリのチェックインです。プロジェクト内のバイナリ コンテンツを簡単に検証またはチェックする方法はないからです。Scorecards は、これを評価する Binary-Artifacts チェックを提供します。

もう 1 つのアンチパターンは、スクリプトで curl | bash を使って動的に依存関係をプルすることです。暗号化ハッシュを使うと、依存関係を既知の値に固定することができます。その値が変更されると、ビルドシステムはそれを検知してビルドを拒否します。依存関係がある場合、依存関係の固定は便利です。これはコンパイル時だけでなく、Dockerfiles や CI/CD ワークフローなどにも当てはまります。Scorecards は、Frozen-Deps チェックによってこのアンチパターンをチェックします。このチェックは、最近の CodeCov 攻撃のような悪意のある依存関係攻撃を軽減する際に役立ちます。

ハッシュを固定したとしても、依存関係で脆弱性の修正が発生すると、ハッシュを更新する必要があります。dependabot や renovatebot といったツールは、ハッシュの確認と更新をする機会を与えてくれます。Scorecards の Automated-Dependency-Update チェックは、デベロッパーがそのようなツールを使って依存関係を更新していることを検証します。

重要なのは、依存関係として取り込む前に、そのプロジェクトの脆弱性を把握することです。Scorecards の新しい Vulnerabilities チェックでは、脆弱性アラート システムをサブスクライブしなくても、この情報が提供されます。

影響力の拡大

現時点で、Scorecards プロジェクトは、50,000 を超えるオープンソース プロジェクトのセキュリティ基準を評価する規模になっています。このプロジェクトを拡大するため、アーキテクチャの大幅な再設計をし、水平スケーラビリティと高いスループットを実現する PubSub モデルを採用しました。この全自動ツールでは、定期的に重要なオープンソース プロジェクトを評価し、毎週更新されるパブリック BigQuery データセットを通して Scorecards チェック情報を公開しています。

このデータは、bq コマンドライン ツールで取得できます。次の例は、Kubernetes プロジェクトのデータをエクスポートする方法を示しています。リポジトリの URL を置き換えると、別のプロジェクトのデータをエクスポートできます。

$ bq query --nouse_legacy_sql 'SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo="github.com/kubernetes/kubernetes"'


分析対象となるすべてのプロジェクトの最新データをエクスポートしたい方は、こちらの手順をご覧ください。

インターネットはどの程度基準を満たしているか

対象プロジェクトの Scorecards データは、最近発表された Google Open Source Insights プロジェクトに含まれており、OpenSSF Security Metrics プロジェクトでも公開されています。これらのサイトのデータからは、Kubernetes などの広く使われているパッケージであっても、埋める必要がある重要なセキュリティ ギャップがまだ存在することがわかります。

また、Google のデータ分析・視覚化ツールの 1 つである Google データポータルで Scorecards データを分析してみました。次の図は、実行されたチェックと、50,000 個のリポジトリに対する合格 / 失格の結果の内訳です。

 


ご覧のように、これらの主要プロジェクトのセキュリティを向上するには、たくさんの作業が必要です。多くのプロジェクトには、継続的なファジングが行われていない、脆弱性報告のセキュリティ ポリシーが定義されていない、依存関係が固定されていないなどの問題があり、これらは一般的な問題のごく一部にすぎません。業界が一丸となってこういった幅広いセキュリティ リスクへの認識を高め、すべての人に利益をもたらすような改善をする必要があります。

実際の Scorecards

いくつかの大規模プロジェクトが Scorecards を採用し、その経験について継続的にフィードバックを行っています。以下に、実際に Scorecards を使った例をご紹介します。

Envoy
以前、Envoy のメンテナンス担当者がプロジェクトに Scorecards を採用し、それを新しい依存関係を導入する際のポリシーに組み込んだ過程についてお話ししました。それ以降、新しい依存関係を Envoy に導入する pull リクエストは、依存関係のメンテナンス担当者からの承認が必要になりました。担当者は Scorecards を使い、一連の基準に照らして依存関係を評価します。

それに加えて、Envoy は独自の Scorecards 評価に基づいて専用のセキュリティ健全性指標を改善する作業にも着手し、現在は C++ の依存関係を固定し、Python の依存関係には pip ハッシュを要求しています。さらに、継続的インテグレーション フローで Github のアクションも固定しています。

以前、Envoy は依存関係についての Scorecards データを CSV として出力するツールを作成し、その結果から表を作成していました。


現在はプロジェクトのデータが増えましたが、Envoy では依存関係についての最新の Scorecard 情報を自動生成し、次のようなドキュメントで公開できるようになっています。


Scorecards
Scorecards 自体のスコアも改善しました。たとえば、CodeCov スタイルの攻撃を防ぐため、依存関係をハッシュで固定するようにしました（Docker 依存関係、ワークフロー依存関係など）。また、この推奨テンプレートに基づいてセキュリティ ポリシーも含めました。

参加する

Scorecards コミュニティが拡大を続けるのを楽しみにしています。現在、このプロジェクトは 23 名のデベロッパーの貢献を受けています。Scorecards の新機能やスケーリングの作業を行ってくださった Azeem、Naveen、Laurent、Asra、Chris に感謝します。

この楽しい作業に参加したい方は、初めての方向けの Issue をご確認ください。

特定のプロジェクトで Scorecards を実行する際にサポートを受けたい方は、GitHub で pull リクエストを送り、こちらにプロジェクトを追加してください。

最後になりますが、私たちにはさまざまなアイデアがあり、追加したいチェックもさらにたくさんありますが、ぜひ皆さんの意見を聞きたいと思っています。Scorecards の次のバージョンで期待するチェックをお知らせください。


次のステップ

次に示すのは、私たちが特に期待している大きな拡張です。
このプロジェクトの成功に貢献してくださった Scorecards コミュニティと OpenSSF の皆さんに改めてお礼を申し上げます。メンテナンスしているプロジェクトで Scorecards を採用しスコアを改善したという方は、ぜひお知らせください。次にお会いするときまで、ぜひスコアの改善を続けてください！

Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Mike Cloonan による Google Ads Developer Blog の記事 "Standalone Gmail campaigns becoming read only in Google Ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2021 年 7 月 8 日より、すべてのスタンドアロン Gmail キャンペーンが読み取り専用になりました。この日以降、新しいキャンペーンの作成、または既存キャンペーンでの広告グループの作成はできなくなりました。この変更は、Google Ads と AdWords API だけでなく、Google 広告アカウントの管理に利用する他のすべてのインターフェースにも適用されます。

具体的に影響を受けるキャンペーンのタイプは、AdvertisingChannelSubType が DISPLAY_GMAIL_AD のものです。この場合、以下の操作は失敗し、エラーは OPERATION_NOT_PERMITTED_FOR_CONTEXT、トリガーは DISPLAY_GMAIL_AD となります。
  • 新しい Gmail キャンペーンの作成
  • 新しい Gmail 広告グループの作成
  • Gmail 広告の作成または更新
既存キャンペーンのデータは引き続き利用できます。

API ユーザーが引き続き Gmail をターゲットにするための一般的な回避策はありません。今後も Gmail をターゲットにしたい場合は、キャンペーンに Gmail 広告が含まれている、Google 広告ウェブ インターフェースでファインド キャンペーンを利用できます。

ご質問やサポートが必要なことがありましたら、フォーラムからご連絡ください。




- Google Ads API チーム、Mike Cloonan
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team


この記事は Andrew Burke による Google Ads Developer Blog の記事 "Asset-based Extensions: Updated Availability and new ValueTrack Parameter" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

以前にお知らせしたように、すべての広告拡張機能は新しいアセットベースの拡張機能に移行します。そのため、実装の拡張機能サポートをアップデートして、既存のフィードベースの拡張機能をアセットベースの拡張機能に移行する必要があります。提供終了に関する重要な日付については、移行スケジュールをご覧ください。

変更内容

現在、以下のアセットベースの拡張機能タイプがすべてのアカウントで利用できます。
Google Ads API のアセットベースのイメージ拡張機能は、当初は今年中にリリースするスケジュールでしたが、2022 年まで利用できない見込みとなりました。利用できるようになった際には、フィードベースのイメージ拡張機能の提供終了タイムラインをアップデートしたものを、このブログと拡張機能移行ドキュメントで公開します。

なお、新しい {extensionid} ValueTrack パラメータは、2021 年 6 月 24 日から利用できるようになりました。このパラメータを使うと、アセットベースの拡張機能でクリックを追跡できます。アセットベースの拡張機能の {extensionid} パラメータは、既存のフィードベースの拡張機能の {feeditemid} パラメータの動作と同じです。

必要になる作業

自分のアカウントのコールアウト、プロモーション、サイトリンク、構造化スニペットの拡張機能を、Google Ads API を利用してアセットベースの拡張機能に移行してください。今後も拡張機能を変更できるように、この作業はできる限り早く行うことをお勧めします。2021 年 10 月 20 日に、コールアウト、プロモーション、サイトリンク、構造化スニペットのフィードベースの拡張機能はアセットベースの拡張機能に自動的に移行されます。近日中に、Google 広告クライアント アカウント単位でオプトアウトをし、この自動移行の対象から外せるようになります。オプトアウトのプロセスが利用できるようになったときは、このブログでお知らせします。最新の関連情報は、拡張機能移行ガイドをご覧ください。なお、AdWords API ではアセットベースの拡張機能がサポートされない点に注意してください。

作成した任意のアセットベースの拡張機能で、クリックを追跡する {extensionid} ValueTrack パラメータを利用できるようになっています。{feeditemid} パラメータはアセットベースの拡張機能のクリックには適用されません。また、{extensionid} はフィードベースの拡張機能のクリックには適用されません。クリックの原因を正しく確認できるように、現在 {feeditemid} ValueTrack パラメータを利用している URL をアップデートし、新しい {extensionid} ValueTrack パラメータも含める必要があります。つまり、同じ URL に {feeditemid} と {extensionid} の両方を設定します。ただし、クリックのソースに基づいて、どちらか片方のみにデータが入ることになります。


ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


- Google Ads API チーム、Andrew Burke
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

...
この記事は  David Wihl による Google Ads Developer Blog の記事 "Broad match modifier upcoming changes in Google Ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 2021 年 2 月 4 日に、フレーズ一致と絞り込み部分一致（BMM）の変更についてお知らせしました。この投稿で説明したように、現時点で、すべての Google 広告の言語がアップデートされ、新しいフレーズ一致定義を使うようになっています。また、現在のところ、以前の BMM キーワードはすべてそのまま利用できる予定ですが、フレーズ一致キーワードとして動作するようになります。2021 年 8 月 2 日以降、以前の BMM 表記（+ キーワード）を使った新しい BMM の作成と既存の BMM キーワード テキストの変更は許可されなくなります（AdWords API、Google Ads API、Google 広告スクリプト）。

その他のターゲット条件項目（ステータス、入札、URL、ラベルなど）の更新は、今後も許可されます。

パートナーの皆さんは、こちらの記事のガイダンスに従ってください。この記事で詳しく説明していますが、BMM キーワードをフレーズ一致に変換する場合、パフォーマンス統計は新しいインスタンスに引き継がれません。スマート入札を使っている方には、部分一致タイプを使うことをお勧めします。

注 : 完全一致、部分一致、除外キーワードのマッチタイプは、フレーズ一致と BMM の変更による影響を受けません。キーワード一致オプションの詳細についてご確認ください。

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


この記事は Alberto Medina による The AMP Blog の記事 "An Easier Path to Great Page Experiences Using AMP for WordPress" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Core Web Vitals という取り組みの目的は、ウェブで優れたユーザー エクスペリエンスを実現するうえで欠かせない品質シグナルに関するガイドを一元的に提供することです。Core Web Vitals は、Google が新しいページ エクスペリエンス ランキング シグナルを計測する際の土台です。これにより、Google 検索で使われる一連のランキング要素に、ユーザー エクスペリエンスが加わることになります。

優れたページ エクスペリエンスの基準を満たすサイトを構築して管理するには、さまざまな要素を考慮して対応することが必要です。サイトオーナーは、測定ツールや自動化ツールの機能を活用してガイドやサポートを得ることができます。サイトの Core Web Vitals を計測するさまざまなツールがあります。また、AMP などの他のツールでも、すぐに使える幅広いパフォーマンス最適化やベスト プラクティスが用意されているので、パフォーマンスのよいウェブサイトを簡単に構築するうえで役立ちます。WordPress プラットフォームを使ってコンテンツを作成、公開している方なら、WordPress の公式 AMP プラグインを使うと、サイトでシームレスに AMP を利用できます。 

この投稿では、WordPress の公式 AMP プラグインを使って構築したウェブサイトのパフォーマンスに注目し、サイトの Core Web Vitals を最適化する際にさらに考慮すべき側面について説明します。また、ガイダンスを得るための AMP プラグイン サポート チャンネルも紹介します。

AMP プラグインの活用

AMP プラグインのランディング ページである amp-wp.org は、AMP プラグイン自体を使って構築されました。つまりこのサイトは、プラグインですぐに利用できる最適化とベスト プラクティスのメリットをすべて享受しています。たとえば、AMP はコンテンツのずれが起きない設計になっているので、通常は CLS の最適化について心配する必要はありません。AMP ページ エクスペリエンス ガイドを使って、このサイトのページ エクスペリエンス関連の動作を確認してみましょう。

ステップ 1: 分析ツールの実行

まず amp.dev/page-experience に移動し、サイトの URL を入力して [Analyze] をクリックします。

ツールが実行され、サイトでさまざまなパフォーマンス テストが行われる間、しばらく待ちます。このツールは、対象ページのページ エクスペリエンスに関連するさまざまな特徴を確認します。

ステップ 2: 結果の解析

すべてのテストが終了すると、AMP ページ エクスペリエンス ガイドにその旨が表示され、サイトの状態について簡潔な概要を確認できます。ご覧のように、amp-wp.org のページ エクスペリエンスは優れていることがわかります。

結果ページを下にスクロールすると、それぞれの Core Web Vital 指標の詳細を見ることができます。

この結果は、パブリッシャーとしてうれしい内容です。AMP が提供するすべてのパフォーマンス最適化とベスト プラクティスにリソースを費やす必要がなく、サイトのパフォーマンスが優れているからです。

CWV をさらに最適化する

自動化ツールを使って Core Web Vitals に影響するたくさんの要素に対処するときは、期待される内容を理解することが重要です。私たちの調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。つまり、AMP などのツールを使うことで、目的の達成に向けて大きく前進することができますが、追加の作業をしてさらにサイトを最適化する必要があるかもしれません。

さらに最適化が必要になるのは、以下のような場合です。

  • ページのヒーロー要素の指定が適切でない場合、一部の最適化が行われません。 
  • 場合によっては、広告によって効率が低下し、読み込み時間が増加して、ページの CWV に影響することがあります。この点を意識し、パフォーマンスが優れた広告ソリューションを使う必要があります。
  • 最初のビューポートに表示される場所に重い埋め込み要素がある場合、ページの初期読み込みが遅くなります。
  • サイトで必要となる主要なイメージの最適化が行われていない可能性があります。

amp-wp.org の場合、スコアは高いものの、AMP ページ エクスペリエンス ガイドにはさらにサイトを改善できる 2 つの推奨事項が表示されています。たとえば、読み込み速度（LCP）を改善するために、ページのヒーロー イメージを適切にマークすることが推奨されています。

これは、ページのヒーロー要素（イメージなど）に data-hero 属性を付けることで、簡単に実現できます。これを行うと、AMP プラグインは自動的にヒーロー イメージをサーバーでレンダリングするようになるので、Largest Contentful Paint（LCP）指標が改善され、ページの CWV スコアが上昇します。

サポートを受ける場所

WordPress の公式 AMP プラグインなどのツールを活用しても Core Web Vitals のパフォーマンスが向上しない場合は、WordPress.org サポート フォーラムを通してプラグインをサポートしているチームに相談したり、質問したり、結果を共有したりできます。皆さんを最大限にサポートいたします。

さらに詳しく知りたい方は、AMP や WordPress の公式 AMP プラグインのサイトをご覧ください。また、こちらの動画シリーズでは、WordPress の AMP プラグインの全貌について、解説や知見をご覧いただくことができます。パフォーマンスやページ エクスペリエンス全般についてさらに詳しく知りたい方は、Google 検索セントラルや web.dev のドキュメントをご覧ください。技術的に有用な情報が多数掲載されています。

投稿者 : Google、AMP と WordPress デベロッパー アドボケート、Alberto Medina


Reviewed by Chiko Shimizu - Developer Relations team

...
この記事は Bob Hancock による Google Ads Developer Blog の記事 "Call Ads Replace Call Only Ads in the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Ads API v8 で、Call Only Ads が Call Ads に置き換わります。AdWords API v201809 と Google Ads API v6 と v7 では、引き続き Call Only Ads を作成できますが、v8 を利用して新しい Call Ads を使うことをお勧めします。

Call Only Ads は、今後も 2022 年 4 月 27 日の AdWords API の提供終了まで利用できます。

v8 より前の Call Only Ads は、ユーザーに電話機能のみを提供します。ユーザーと広告主からは、この広告から直接ウェブサイトに移動できる機能の需要がございました。Call Ads に final URL が追加されたことで、電話を主な（ヘッドライン）アクションとして使いつつ、電話する前や電話する代わりに、広告主のウェブサイトに移動する手段も提供できるようになります。

必要になる作業
  • 新しい Call Ads を作るには、広告タイプで CallOnlyAd の代わりに CallAd を使います。
  • 広告を作る際に使われた ad.type にかかわらず既存の広告の情報を取得したい場合は、ad.type = 'CALL_AD' で絞り込みます。たとえば、Google Ads API で次のクエリを実行すると、 
        SELECT ad_group_ad.ad.call_ad.country_code,
           ad_group_ad.ad.call_ad.phone_number
    FROM ad_group_ad
    WHERE ad_group_ad.ad.type = 'CALL_AD'
    CALL_ONLY_AD と CALL_AD で作られた広告が返されます。
変更内容
追加項目
ad_group_ad.ad.final_urls ここにウェブサイトの URL を指定します。
path1 広告に表示する URL に追加して表示できるテキストの最初の部分です。
path2 広告に表示する URL に追加して表示できるテキストの 2 つ目の部分です。この項目は、path1 を設定した場合のみ設定できます。
削除項目
ad.display_url Call Only Ads の display_url を削除しました。
広告に表示される URL は、
ad_group.ad.final_urls （提供された場合）か
phone_number_verification_url
（ad_group.ad.final_urls が空欄の場合）となります。
加えて、path1 と path2 で指定した追加テキストが表示されます。
項目の検証
phone_number_verification_url ad_group.ad.final_urls が空の場合、この項目が必須になります。

AdWords API レポート : AdWords API では変更はありません。

Google Ads API レポート : Google Ads API では、以下の新しい項目をクエリに含めることができるようになります。

サポートを受ける場所
Call Ads について疑問に思うことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。



Google Ads API チーム、Bob Hancock