今後、Google 広告スクリプトで search リクエストと、Google Ads Query Language を使う report リクエストを対象に、デフォルトのレポート バージョンの更新方法を変更します。これまでは、最大数か月にわたって新しいバージョンが利用できない期間がありましたが、今後は新しいレポート機能がリリースされたまもなくアクセスできるようになります。この変更は、v201809 の AdWords API ベースのレポートを使い続けている方には影響しません。
今後は最新バージョンの Google Ads API のリリースから 2 週間以内に、デフォルトのレポート バージョンを更新し、最新バージョンが使えるようになります。たとえば、v8 がリリースされるとその 2 週間以内に、GAQL を使う report 呼び出しと、すべての search 呼び出しについて、デフォルトのレポート バージョンを更新し、v8 を使うようにします。
スクリプトに悪影響が生じる可能性があり特定のバージョンに固定したい場合、手動でバージョンを指定することもできます。これはデフォルトよりも優先されるので、次のバージョンの準備が整うまでアップデートを延期できます。延期する場合、Google Ads API のバージョンが提供終了になるタイミングに注意してください。新しいバージョンにアップデートしないと、スクリプトが失敗します。API のバージョンを設定する例を次に示します。
report の場合 :
var report = AdsApp.report(query, {apiVersion: 'v7'});
search の場合 :
var results = AdsApp.search(query, {apiVersion: 'v7'});
Google Maps Platform JavaScript チームが行っている、Maps JavaScript API のユーザー補助機能の改善に重点を置いた最近の機能変更をいくつかご紹介します。当チームは 2020 年に、すぐに使えるユーザー補助機能と、デベロッパーがユーザー補助エクスペリエンスを作成するために利用できるフックを増やす新たな取り組みを開始しました。
Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。お客様にはこうした新機能を毎週の最新バージョンでお試しいただき、変更点に関するフィードバックの提供と新しいバグの報告にご協力いただけますと幸いです。それらを参考に、最も影響の大きい領域に優先順位を付けさせていただきます。みなさんのウェブサイトに影響を与える既存のバグに +1 し、新しいバグレポートをご提出ください。ユーザー補助機能は、さまざまなユーザーやコミュニティに多様な影響を与える複雑なトピックです。お客様のフィードバックは、Google Maps Platform の機能を誰でも利用できるようにする取り組みの指針として活用されます。
最後に、コア日付セグメントによるフィルタが有限の範囲になる場合、それを組み合わせたときに少なくとも 1 日の範囲になることをチェックします。たとえば、フィルタ条件 WHERE segments.date = ‘2021-01-01’ AND segments.date BETWEEN ‘2021-02-01’ AND ‘2021-03-01’ を含むクエリは、両方のフィルタ条件を満たす日付が存在しないので、失敗します。この場合はエラーが生成されます。ただし、フィルタ条件 WHERE segments.date BETWEEN ‘2021-01-01’ AND ‘2021-01-31’ AND segments.date >= ‘2021-01-15’ AND segments.date < ‘2021-03-01’ は有効です。すべてのフィルタ条件を満たす日付範囲は ‘2021-01-15’ - ‘2021-01-31’ なので、エラーは生成されません。
click_view の日付フィルタが有効である
click_view が FROM 句のメインリソースである場合、他の選択内容にかかわらず、WHERE 句に直近 90 日間の 1 日を指定する日付フィルタが存在しなければなりません。
change_event と change_status の日付フィルタが有効である
FROM 句のリソースが change_event または change_status である場合、「コア日付の選択が有効である」ルールと同じように、WHERE 句のフィルタ条件で有効な日付範囲が指定されている必要があります。ただし、この条件はクエリに日付フィールドがあるかどうか関係なく適用されます。さらに、コア日付セグメントではこのフィルタ条件は生成されません。FROM 句のメインリソースが change_event または change_status である場合、利用できるコア日付セグメントはないからです(パート 4 参照)。FROM 句のリソースが change_event である場合、Google Ads API サーバーで change_event.change_date_time フィールドのフィルタに対して日付の評価が行われます。FROM 句のリソースが change_status である場合、Google Ads API サーバーで change_status.last_change_date_time フィールドに対して日付の評価が行われます。
現在、change_status レポートにいくつかの新しいリソースタイプを追加する作業を懸命に進めています。今後、shared_set や asset などを改善する予定です。これらのタイプは今後のバージョンの Google Ads API で完全にサポートされますが、そのために現在行っているインフラストラクチャの変更作業によって、既存のバージョンにも多少の影響が発生します。
新しいリソースタイプのサポートが追加されると、すべてのバージョンの API で新しい行を取得できるようになります。その際に、すでにリリースされているバージョンでは、resource_type が UNKNOWN として返却されます。具体的には、これまで CAMPAIGN などの既知の resource_type が返されていた行で、UNKNOWN リソースタイプが返される場合があります。これが発生するのは、これまで CAMPAIGN の変更と報告されていた変更が、実際には CAMPAIGN_ASSET の変更だった場合などです。今後のバージョンの API は CAMPAIGN_ASSET リソースタイプを認識しますが、既存のバージョンは認識しないので、UNKNOWN を使うしかありません。この行には、新しい resource_name も関連付けられ、アセットの ID が含まれるようになります。
その行の新しいリソース名には、変更の種類を表す識別子が含まれます。最新の識別子のリストは、ステータス変更ガイドをご覧ください。これを調べる必要があるのは、UNKNOWN リソースタイプが含まれる行だけです。これにより、今後の API バージョンでそのリソースタイプが完全にサポートされたときに返されるリソースタイプがわかります。
Intl.DateTimeFormat() メソッドに dayPeriod オプション(ECMA402 2021 の一部)が追加され、呼び出し元が時間を「7 in the morning」、「11 in the morning」、「12 noon」、「1 in the afternoon」、「6 in the evening」、「10 at night」などの形式(または中国語で「清晨 7 時」、「上午 11 時」、「中午 12 時」、「下午 1 時」、「下午 6 時」、「晚上 10 時」)を指定できるようになりました。
Media Session API に "togglemicrophone"、"togglecamera"、"hangup" アクションが追加されました。これにより、ビデオ会議サイトのデベロッパーが、ブラウザのインターフェースでこれらのアクションを扱えるようになります。たとえば、ユーザーがビデオ通話をピクチャー イン ピクチャー ウィンドウにした場合、ミュート / ミュート解除、カメラのオン / オフ、通話終了のボタンをブラウザに表示できます。ユーザーがこれらをクリックすると、ウェブサイトは Media Session API を通して処理できます。詳細については、最新記事の該当セクションを参照するか、デモをお試しください。
リソースが(リダイレクトによって)2 つのオリジンにまたがる場合、このチェックを通過するために Timing-Allow-Origin: * を使用する必要があります。たとえば、オリジン A のページがオリジン B のリソースをフェッチし、オリジン B のリソースからオリジン C のリソースにリダイレクトされる場合、Tainted Origin フラグが設定され、最終的なリソースが詳細なタイミング情報を受け取るには、Timing-Allow-Origin: * が必要になります。
Web Bluetooth のメーカーデータ フィルタ
Web Bluetooth API で、ベンダー ID やプロダクト ID などのメーカーデータによるフィルタが可能になります。これまでも、近くにある Bluetooth デバイスで、アドバタイズされる名前やサービスに一致するものをブラウザのピッカーで選択することはできました。しかし、近くにある Bluetooth デバイスを、アドバタイズされるメーカー固有のデータで絞り込むことはできませんでした。メーカーのデータは、options.filters の新しいプロパティで指定し、Bluetooth.requestDevice() に渡します。詳細については、JavaScript で Bluetooth デバイスと通信するを参照するか、デモをお試しください。
ルール 2: すべてのセグメント、セグメント化リソース、指標、属性付きリソースのフィールドは、SELECT 句に存在しなければ ORDER BY 句に挿入することはできません。言い換えるなら、最初に SELECT 句に挿入することなく ORDER BY 句に配置できるのは、FROM 句のリソースのフィールドだけです。
Google for Startups は、成長段階にある日本の有望なスタートアップを対象に 8 週間のオンライン プログラム「Growth Academy 2021」を開催します。Google の社員や外部のアドバイザーが、メンタリング セッション、ワークショップなどを通じてスタートアップの成長を支援します。
incompatibleSelected というインスタンス変数で、メインリソースの各フィールドについて、同時に選択できないフィールドのうち現在選択されているものを追跡します。この変数は、それぞれのフィールドを、同時に選択できないフィールドのうち現在選択されているものの一覧を表す Set にマッピングします。
フィールドの選択を解除するたびに、最初にそのフィールドがクエリのいずれかの句に含まれているかをチェックする必要があります(詳しくはパート 6 で説明します)。含まれている場合は、incompatibleSelected を更新すべきではないからです。たとえば、segments.ad_destination_type が SELECT 句と ORDER BY 句で選択されており、ORDER BY でのみ選択解除された場合、まだ segments.ad_destination_type がクエリに含まれているので、incompatibleSelected マップを変更してはいけません。ただし、選択解除されたフィールドがどの句にも含まれていない場合は、Set(選択解除されたフィールドとは同時に選択できないフィールドの集合)からそのフィールドを削除できます。
この記事では、Maps JavaScript API の新しい WebGL による機能の簡単な概要をご紹介します。これにより、次世代のマッピング エクスペリエンスを作成するために十分な知識が得られます。
WebGL とは
WebGL は低レベルのブラウザ API で、元は Mozilla Foundation により作られたものです。この API を使用すれば、スマートフォンやコンピュータなどのクライアント デバイスの GPU のレンダリング能力や処理能力を、ウェブアプリから利用できます。ブラウザ単独では、3D 空間のオブジェクトのレンダリングといった重い処理を実行することはできませんが、WebGL を使用すれば、そのような処理に特化して設計されたクライアント側の GPU で実行できます。
WebGL について詳しくは、WebGL の設計と保守をしている Khronos Group のドキュメントをご覧ください。
要件
WebGL Overlay View を使用するには、ベクターマップが有効な Map ID が必要です。また、マップ ID を作成するときは、傾きと回転を有効にすることを強くおすすめします。これを有効にしないと、マップはデフォルトの真上からのビューに限定されます。言い換えると、マップを 3 次元的に動かすことはできません。
WebGL による Maps JavaScript API の新しい機能は、Beta チャンネルから API を読み込んで、今すぐ試すことができます。すぐに開発を始められるよう、新しい Codelab、すべての詳細が記されたドキュメント、サンプルコード、より詳細なサンプルアプリを用意しています。また、機能ツアーやトラベルのデモで詳細をご確認いただけます。さらに、これらの機能の実装をお試しいただけます。