Google BigQueryのカスタムディメンション

Question

私は大きなクエリを使用しており、非カスタムディメンションとともにカスタムディメンションをインポートしようとしています。アナリティクスはアプリから送信され、基本的には、UserID（カスタムディメンション）、platformID（カスタムディメンション）、ScreenName（基本的に「ページ名」のアプリバージョン）、および日付の列を持つ表が必要です。測定基準は、これらのすべてのディメンションにグループ化された「スクリーンビューの数」です。これは、以下のようになります。

GAレポートの写真：

ので、BigQueryの中で、私は（上記GAレポートと比較して）Iまでチェックアウトの数字を得ることができますカスタムディメンションで追加されました。一度カスタムディメンションを追加すると、数値は意味をなさないようになりました。

カスタムディメンションが大きなクエリ内にネストされていることがわかりました。だから私はまずFLATTENを使うようにしました。その後、私は平らにすることなく試して、同じ結果を得ました。数字は意味をなさない（GAインターフェースの何百倍も大きい）。

私のクエリは以下のとおりです（1つはFLATTENなし、もう1つはFLATTEN）。私は理想的な代わり

count(hits.appInfo.screenName) 

の

count(hits) 

を使用していた。しかし、私は私が私のサブクエリでヒットを選択したときにエラーを取得保管

PS。

Flattenを使用しないクエリは次のとおりです。あなたは私を見つけ出す手助けができれば、なぜ私はカスタム寸法を追加すると、すべてのデータが

SELECT 
    date, 
    hits.appInfo.version, 
    hits.appInfo.screenName, 
    UserIdd, 
    platform, 
count(hits.appInfo.screenName) 


FROM (
      SELECT 
      date, 
      hits.appInfo.version, 
      hits.appInfo.screenName, 
      max(case when hits.customdimensions.index = 5 then hits.customdimensions.value end) within record as UserIdd, 

      max(case when hits.customdimensions.index = 20 then hits.customdimensions.value end) within record as platform 



      FROM 
      TABLE_DATE_RANGE([fiery-cabinet-97820:87025718.ga_sessions_], TIMESTAMP('2017-04-04'), TIMESTAMP('2017-04-04')) 

      ) 

    where UserIdd is not null 
    and platform = 'Android' 

GROUP BY 
    1, 
    2, 
    3, 
    4, 
    5 
ORDER BY 
    6 DESC 

を台無しにされることを、それをされ、ここでFLATTENと私のクエリです（同じ問題 - 数字が意味をなすいけない）

SELECT 
date, 
hits.appInfo.version, 
    customDimensions.index, 
    customDimensions.value, 
    hits.appInfo.screenName, 
    UserIdd, 
count(hits.appInfo.screenName) 

FROM (FLATTEN((FLATTEN((
      SELECT 
      date, 
      hits.appInfo.version, 
      customDimensions.value, 
      customDimensions.index, 
      hits.appInfo.screenName, 
      max(case when hits.customdimensions.index = 5 then hits.customdimensions.value end) within record as UserIdd, 
      hits.type 

      FROM 
      TABLE_DATE_RANGE([fiery-cabinet-97820:87025718.ga_sessions_], TIMESTAMP('2017-04-04'), TIMESTAMP('2017-04-04'))), customDimensions.value)),hits.type)) 

WHERE 
    customDimensions.value = 'Android' 
    and customDimensions.index = 20 
    and UserIdd is not null 


GROUP BY 
    1, 
    2, 
    3, 
    4, 
    5, 
    6 
ORDER BY 
    7 DESC 

Answer 1

hits.customDimensions.*は常にユーザースコープのディメンションを持つことは肯定的ではありません（ユーザースコープのuserIdメトリックを推測しています）。

具体的には、ユーザースコープのディメンションはcustomDimensionsではなく、hits.customDimensionsです。

概念的には、最初のステップは、平坦化またはスコープ付き凝集を介してhits.*と互換性を持たせることです。フラット化のアプローチについて説明します。

GAレコードの形状は(customDimensions[], hits[], ...)で、両方のフィールドを照会するのには適していません。まず、これらを平らにして(customDimensionN, hits[], ...)にします。

レベルを1つ上にして、hits.*の下にあるフィールドを選択すると、暗黙的にテーブルが(customDimensionN, hitN)レコードにフラット化されます。 (customDimension5, appviewN)に一致するレコードのみを含めるようにフィルタリングします。

最後のステップはすべてをカウントすることです。

SELECT date, v, sn, uid, COUNT(*) 
FROM (
    SELECT 
     date, 
     hits.appInfo.version v, 
     hits.appInfo.screenName sn, 
     customDimensions.value uid 
    FROM 
     FLATTEN((
      SELECT customDimensions.*, hits.*, date 
      FROM 
      TABLE_DATE_RANGE(
       [fiery-cabinet-97820:87025718.ga_sessions_], 
       TIMESTAMP('2017-04-04'), 
       TIMESTAMP('2017-04-04'))), 
     customDimensions) 
WHERE hits.type = "APPVIEW" and customDimensions.index = 5) 
GROUP BY 1,2,3,4 
ORDER BY 5 DESC 

これと同等のアプローチがあります。これは、GA BQのクックブックで推奨されているスコープの集約トリックを使用します。しかし、クエリの説明を見ると、MAX(IF(...)) WITHIN RECORDは非常に高価なように見え、最初の段階ではCOMPUTEとAGGREGATEの相が余計にトリガされます。しかし、もう少し消化しやすいボーナスポイント。

SELECT sn, uid, date, v, COUNT(*) 
FROM (
    SELECT 
     MAX(IF(customDimensions.index = 5, customDimensions.value, null)) within record as uid, 
     hits.appInfo.screenname as sn, 
     date, 
     hits.appInfo.version as v, 
     hits.type 
    FROM 
     TABLE_DATE_RANGE([fiery-cabinet-97820:87025718.ga_sessions_], TIMESTAMP('2017-04-04'), TIMESTAMP('2017-04-04'))) 
WHERE hits.type = "APPVIEW" and uid is not null 
GROUP BY 1,2,3,4 
ORDER BY 5 DESC 

私はまだBQの標準SQL方言に精通していませんが、このような暴言を単純化すると思われます。あなたはこのような多くのクエリを作成する場合は、あなたの頭を包むことがあります。