Search Console APIで全検索データを取得する
以下はGetting all your search dataの訳である。
割り当てを超過しないで、すべての検索分析データを素早く得ることができる。価値のあるデータ一日分を日々問い合わせることによってだ。
※訳注:一日の問い合わせ回数割り当ては最大100万回
データ中にどんなものを求めるかを選択しなければならない。検索タイプ(web、image、video)、ディメンジョン(page、query、country、device)、それとまた、結果をpageやpropertyでグループするか否かだ。pageあるいはquery、あるいは両方で問い合わせを行うとデータが欠落するかもしれない(理由は後述する)。
概要
- 価値あるデータ一日分を毎日問い合わせることを推奨する。後述する問い合わせスタイルを使ってである。一日分の問い合わせは、一日分の問い合わせ制限を越えることはない。データは典型的に2、3日の後に利用可能になる。日付でグループ化された単純なクエリを使うことにより、過去10日間の間の最も最近の日付を得ることができるだろう。問い合わせを書く場合には、
- pageあるいはpropertyでグループ化するかを決める
- 問い合わせの中に、より完全なカウントあるいはディメンジョンを必要とするかを決める。注意:search appearanceデータ(AMP, blue link, rich resultなど)は2ステップのプロセスが必要になる。
- startRowを25,000ずつ増加させることにより、同じ問い合わせについてのすべてのページを得ていく、最後のページになるまでだ(応答が0行になる)。
- オプションで、同じ問い合わせを新たなsearchTypeパラメータを使って行う。
以下は、一つの問い合わせの疑似コードだ。これを、欲しいsearchType値(web, image, video)について、一日に一度走らせる。
int maxRows = 25000; // 現在の最大応答行数
int i = 0;
do {
response = Request(startDate = 3日前,
endDate = 3日前,
... dimensions, searchType を追加する...
rowLimit = maxRows,
startRow = i * maxRows);
i++;
… // 応答データについて何かしらする
} while (response.rows.count() != 0); // 結果行の全ページを見ていく
問い合わせの詳細
問い合わせはpageあるいはpropertyでグループ化できる。
pageでのグループ化
※訳注:ここで言うページとは、ウェブサイトのページのこと。つまり、「https://www.gwtcenter.com/foo-bar-page」など。
正確な数量を得るには、dimensionからpageとqueryを省略しなければならない。以下のようになる。
"startDate": "2018-06-01",
"endDate": "2018-06-01",
"dimensions": ["country", "device"],
"searchType": "web",
"aggregationType": "byPage"
- startDate / endDate:一日分を選択する
- dimensions:オプションでcountryあるいはdevice、その両方を含める
- searchType:web、image、videoそれぞれを別の問い合わせで繰り返す。
- aggregationType:”byPage”でなければいけない。
より詳細を得るには、pageかquery、あるいはその両方を含めるが、ただし、何らかのデータを失うという代償がある。このようにする。
"startDate": "2018-06-01",
"endDate": "2018-06-01",
"dimensions": ["page", "query", "country", "device"],
"searchType": "web"
- startDate / endDate:一日分を選択する
- dimensions:pageを含める。オプションでquery、country、deviceの任意の組み合わせを含める。
- searchType:web、image、videoそれぞれを別の問い合わせで繰り返す。
propertyでのグループ化
正確な計測のためには、pageとqueryは省略しなければならない。以下のようにだ。
"startDate": "2018-06-01",
"endDate": "2018-06-01",
"dimensions": ["country", "device"],
"searchType": "web"
- startDate / endDate:同じ日付を選択して一日分とする
- dimensions:オプションでcountry, deviceを追加する。
- searchType:オプションで、web, image, videoのそれぞれについて同じ検索を行う。
詳細を得るには、query, country, device等を追加するが、しかし、データを失う代償があるかもしれない。
"startDate": "2018-06-01",
"endDate": "2018-06-01",
"dimensions": ["query", "country", "device"],
"searchType": "web"
- startDate / endDate:同じ日付を選択して一日分とする
- dimensions:オプションでquery, country, deviceを追加する。
- searchType:オプションで、web, image, videoのそれぞれについて同じ検索を行う。
pageあるいはpropertyで結果をグループ化する
propertyではなくpageでグループ化すると、impression、clicks、position、ctrは異なる計算のされ方になる。詳細はここだ。
より詳細を求めるとなぜデータを失うのか?
pageかquery、あるいはその両方でグループ化すると、我々のシステムは何らかのデータを失うかもしれないが、これは合理的な計算リソースを使い、合理的な結果を計算するためだ。
search appearanceデータを取得する
※訳注:search appearanceとは、旧サーチコンソールにあった「検索での見え方」のことと思われる。なぜか現在のサーチコンソールには存在しない。
search appearance列は、他のdimensionと共に現れることは無い。したがって、もしsearch appearanceを見たいのであれば、以下のステップに従う必要がある。
- searchAppearanceを唯一のdimensionとして指定すること。これにより、search appearanceのみで全データがグループ化される。
- オプションで二番目の問い合わせを走らせる。1.で得られるappearance typeの一つでフィルタリングし、他の所望のdimensionを加える(page, country, queryなど)。
複数のsearch appearanceタイプについてデータを取得するには、1でリストされたsearch appearance typeについて二番目の問い合わせを行わねばならない。
最初の問い合わせ
すべてのsearch appearanceタイプを取得する。
{
"startDate": "2018-05-01",
"endDate": "2018-05-31",
"searchType": "web",
"dimensions": [
"searchAppearance"
]
}
結果
INSTANT_APP, AMP_BLUE_LINKなどがある。
"rows": [
{
"keys": [
"INSTANT_APP"
],
"clicks": 443024.0,
"impressions": 4109826.0,
"ctr": 0.10779629113251997,
"position": 1.088168452873674
},
{
"keys": [
"AMP_BLUE_LINK"
],
"clicks": 429887.0,
"impressions": 1.7090884E7,
"ctr": 0.025152999692701676,
"position": 7.313451603790653
},...
第二クエリ
ステップ1で現れたsearch appearanceでフィルタリングし、所望のdimensionを加える(page, deviceなど)。ここではAMP_BLUE_LINKをフィルターした。
{
"startDate": "2018-05-01",
"endDate": "2018-05-31",
"searchType": "web",
"dimensions": [
"device" // and/or page, country, ...
],
"dimensionFilterGroups": [
{
"filters": [
{
"dimension": "searchAppearance",
"operator": "equals",
"expression": "AMP_BLUE_LINK"
}
]
}
]
}
結果
AMP_BLUE_LINKのデバイスタイプでの分析だ。
"rows": [
{
"keys": [
"MOBILE"
],
"clicks": 429887.0,
"impressions": 1.7090783E7,
"ctr": 0.025153148337323107,
"position": 7.31339517914422
},
{
"keys": [
"DESKTOP"
],
"clicks": 0.0,
"impressions": 66.0,
"ctr": 0.0,
"position": 12.257575757575758
},
...