Přidání šumu

Přidávání šumu je technika používaná k ochraně soukromí uživatelů při spouštění dotazů na databázi. Funguje na principu přidávání náhodného šumu do agregujícího příkazu SELECT v dotazu. Tento šum chrání soukromí uživatelů a přitom umožňuje získání přiměřeně přesných výsledků. Díky tomu není potřeba provádět kontrolu rozdílů a na výstup lze uplatnit menší agregační práh. V režimu šumu lze spustit většinu stávajících dotazů, existují však určité výjimky.

Výhody přidávání šumu

Není třeba provádět kontroly rozdílů: Jestliže do dotazu přidáte šum, Ads Data Hub nebude filtrovat řádky kvůli podobnosti s předchozími výsledky. To znamená, že získáte komplexní pohled na data a zároveň chráníte soukromí uživatelů.

Jednodušší odstraňování problémů: Řádky jsou vynechávány pouze kvůli požadavku na agregaci, takže je snazší v dotazech odstraňovat problémy a upravovat je.

Není třeba se učit novou syntaxi: Abyste mohli využívat šum namísto kontroly rozdílů, nemusíte se učit žádnou novou syntaxi dotazů ani mít rozsáhlé znalosti ochrany soukromí.

Jasná přesnost výsledků: V případě úspěšně provedené úlohy je zobrazeno celkové procento dat s očekávaným množstvím šumu.

Vliv šumu na požadavky na ochranu soukromí

Kontroly rozdílů: Přidávání šumu nevyužívá stávajících kontrol rozdílů ve službě Ads Data Hub. Jestliže využijete funkci přidání šumu, kontrola rozdílů vůbec nebude provedena.

Požadavek na agregaci: Výstupem funkce přidání šumu jsou data o zobrazeních, představovaná asi 20 či více unikátními uživateli, a data o kliknutích či konverzích, představovaná asi 10 či více unikátními uživateli.

Statické kontroly: Nemá žádný vliv.

Limity pro dotazy a přístup k datům: Dotazy prováděné s použitím šumu sdílejí limit přístupu k datům, který se používá při kontrolách rozdílů. Stejně jako u kontrol rozdílů platí, že pokud provedete stejný dotaz na stejný soubor dat mnohokrát, můžete ztratit přístup k často dotazovaným datům v souboru dat. Může se to stát, pokud spouštíte dotazy s klouzavým obdobím nebo opakovaně provádíte stejný požadavek.

Režim šumu zavádí další, přísnější omezení pro přepočítávání stejných souhrnných výsledků v rámci dotazů nebo různých dotazů. Stejně jako v případě limitu přístupu k datům můžete ztratit přístup k často dotazovaným datům v souboru dat, ale omezení v důsledku přepočítávání stejných souhrnných výsledků omezí pouze dotazy v režimu šumu, nikoli dotazy v režimu kontroly rozdílů. Další informace viz část Opakované výsledky.

Další informace o kontrolách ochrany soukromí

Vliv přidávání šumu na výsledky

Služba Ads Data Hub šum přidává, aby omezila riziko prozrazení, tedy riziko, že někdo bude schopen zjistit údaje o konkrétní osobě. Vyvažuje ochranu soukromí a využitelnost.

Přidání šumu ve službě Ads Data Hub transformuje výsledky dotazu takto:

• Omezí vliv nestandardních uživatelů na agregované výsledky. Spočítá souhrnný příspěvek každého uživatele k agregovaným datům a poté každý příspěvek omezí podle minimálních a maximálních limitů omezení.
• Takto omezené příspěvky jednotlivých uživatelů jsou pak agregovány.
• Poté je přidán šum k jednotlivým výsledkům agregace, tedy výsledkům volání agregační funkce pro jednotlivé řádky. Rozsah tohoto náhodného šumu je úměrný limitům omezení.
• Je vypočten počet uživatelů se zahrnutím šumu a poté jsou odstraněny řádky, v nichž je uživatelů příliš málo. Je to podobné jako u k-anonymity v režimu kontroly rozdílů, ale kvůli šumu mohou úlohy běžící na stejné datové sadě vypouštět různé řádky. V režimu šumu je také vynecháváno méně řádků, protože požadavek na agregaci je nižší (přibližně 20 oproti přesně 50).

Konečným výsledkem je soubor dat, v němž každý řádek obsahuje agregované výsledky s aplikovaným šumem a z nějž byly vynechány příliš malé skupiny. Tím je zakryt vliv jednotlivých uživatelů na vrácené výsledky.

Omezování agregace

Při přidávání šumu ve službě Ads Data Hub se vliv nestandardních uživatelů zmenšuje pomocí implicitního nebo explicitního omezování agregace. Používaný typ omezování si můžete zvolit podle toho, který se pro váš konkrétní případ použití hodí.

Implicitní omezování

Při implicitním omezování jsou limity určeny automaticky. K jeho použití není potřeba žádná zvláštní syntaxe jazyka SQL. Pokud je v jednom řádku větší rozsah hodnot než v jiném, najde tato metoda pro každý z nich jiné limity. To zpravidla vede k menší mezní odchylce jednotlivých výsledků. Na druhé straně každá agregace používá jiné limity omezení a úroveň šumu, což může zkomplikovat porovnávání.

Jestliže agregace pracuje s daty od příliš malého počtu uživatelů, může implicitní omezování selhat. Může to nastat například při volání funkce COUNTIF() s velmi neobvyklou podmínkou. V těchto případech je vrácen výsledek NULL. Také si všimněte, že COUNT(DISTINCT user_id) automaticky používá explicitní omezování s hranicemi 0 a 1.

Explicitní omezování

Explicitní omezování limituje celkový příspěvek každého jednotlivého uživatele tak, aby spadal do stanoveného rozsahu. Explicitní limity jsou aplikovány stejně na všechny řádky. Musí jít o literálové hodnoty. Stejné limity jsou na všechny řádky použity i v případě, že některé řádky mají větší rozsah příspěvků jednotlivých uživatelů než jiné. Proto je snazší jednotlivé řádky porovnávat, některé řádky však mohou obsahovat více šumu než v případě implicitního omezování.

Explicitní omezování používá poloviční množství šumu, než jaké by pro dané limity bylo použito při omezování implicitním. Pokud tedy dokážete odhadnout rozumné meze, dosáhnete lepších výsledků jejich explicitním stanovením.

Pokud chcete použít explicitní omezování, stanovte limity pro všechny podporované agregační funkce tím, že zadáte celá čísla představující spodní a horní limit. Příklad:

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

Spuštění dotazu s přidáním šumu

1. Napište dotaz nebo otevřete existující dotaz. Pokud chcete zjistit, které agregační funkce lze použít, podívejte se na podporované funkce.
2. V editoru dotazů klikněte na Spustit a zadejte podrobnosti o nové úloze.
3. Přepněte přepínač Nastavení ochrany soukromí do pozice Používat šum.
4. Spusťte dotaz.
5. Zkontrolujte přidaný šum.
6. Nepovinné: Přizpůsobte dotaz tak, abyste omezili vliv šumu.

Kontrola vlivu šumu

Po úspěšném provedení dotazu zobrazí služba Ads Data Hub spolehlivost výsledku založenou na tom, kolik buněk ve výstupu obsahuje očekávané množství šumu. Jestliže škála šumu přidaného k určité hodnotě ve výsledkové tabulce překračuje 5 % výsledku v dané buňce, je tato hodnota považována za výrazně ovlivněnou. Rozsahy dopadů jsou uvedeny v následující tabulce.

U ovlivněných výstupních souborů dat je v tabulce s podrobnostmi uvedeno 10 sloupců s největším množstvím šumu, seřazených od nejvíce ovlivněných k nejméně ovlivněným, a jejich příspěvek k šumu. Jde o rozdělení očekávaného množství šumu.

Data s očekávaným množstvím šumu	Barva indikátoru	Vliv
> 95 %	Zelená	Malý vliv
85–95 %	Žlutá	Střední vliv
75–85 %	Oranžová	Výrazný vliv
< 75 %	Červená	Velmi výrazný vliv

Zobrazení podrobných informací o vlivu šumu:

1. Klikněte na Přehledy.
2. Ze seznamu vyberte přehled. V popisku se souhrnem ochrany soukromí je uvedeno procento výsledků, které obsahují očekávané množství šumu, což odpovídá množství přidaného šumu, které je větší než 5 % výsledku.
3. Pokud se chcete podívat na další informace, klikněte na Úlohy > Podrobnosti.
4. V podrobnostech o úloze se podívejte na Informace o soukromí. Výsledky spadají do jedné z uvedených kategorií.
5. V případě potřeby dotaz upravte, abyste dosáhli lepších výsledků.

Přizpůsobení dotazů

To, že agregované výsledky budou obsahovat neočekávané množství šumu, je pravděpodobnější, pokud jsou založeny na menším počtu uživatelů. To se může stát, když řádky obsahují méně uživatelů nebo když někteří uživatelé nemají vliv na výsledky, například při použití funkce COUNTIF. Může být vhodné na základě informací o šumu dotaz upravit tak, aby se zvětšilo procento dat obsahujících očekávané množství šumu.

Obecně lze doporučit toto:

• Prodlužte období, na které se dotaz vztahuje.
• Přepište dotaz tak, aby se zmenšila granularita dat, například seskupením podle menšího počtu parametrů nebo tím, že COUNTIF nahradíte COUNT.
• Odstraňte sloupce se šumem.
• Použijte explicitní omezování.

---

Podporované agregační funkce

Přidávání šumu je podporováno u těchto agregačních funkcí:

• SUM(...)
• COUNT(*)
• COUNT(...)
• COUNTIF(...)
• COUNT(DISTINCT user_id)
• APPROX_COUNT_DISTINCT(user_id)
• AVG(...)

Klíčové slovo DISTINCT je podporováno pouze u funkce COUNT a pouze při použití s přímým odkazem na sloupec user_id z tabulky služby Ads Data Hub nebo s výrazem, který vrací user_id či NULL, například COUNT(DISTINCT IF(..., user_id, NULL)).

Níže uvedené funkce přímo podporovány nejsou, statistické výsledky však můžete získat jejich nahrazením jinými způsoby agregace, které šum podporují. Číselné hodnoty představují pouze příklady.

• LOGICAL_OR(...). Doporučená náhrada: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
• LOGICAL_AND(...). Doporučená náhrada: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

Celočíselné výsledky

Ačkoli služba Ads Data Hub bude u těchto agregačních funkcí automaticky přidávat šum, jejich definice se nezmění. Protože funkce COUNT, SUM a další použité na celočíselné hodnoty typu INT64 vrací také hodnoty typu INT64, bude případná desetinná složka šumu zaokrouhlena. Relativně k velikosti výsledku a šumu je to zpravidla zanedbatelné.

Pokud ve výsledcích potřebujete desetinnou přesnost, nepoužívejte funkce, které vracejí typ INT64. Můžete například použít funkci SUM se vstupem přetypovaným na FLOAT64.

---

Podporované typy dotazů

Důležité: Většina standardních doporučených postupů služby Ads Data Hub platí i pro dotazy s přidáváním šumu. Zejména doporučujeme, abyste si přečetli pokyny k opakovanému dotazování na stejná data.

Tato část popisuje typy dotazů podporované v dotazech využívajících přidání šumu.

Agregace na úrovni uživatele

Neomezená agregace na úrovni uživatele je podporována stejně jako v režimu kontroly rozdílů. Šum je přidáván pouze do agregací, které kombinují data různých uživatelů. Do agregací, které explicitně seskupují podle user_id, a do analytických funkcí rozdělujících podle user_id není šum vkládán a jsou povoleny všechny funkce. Agregace na úrovni uživatelů, které neseskupují explicitně podle user_id, například GROUP BY impression_id, jsou považovány za agregace s více uživateli a je do nich tedy přidán šum.

Seskupování podle external_cookie nestačí. Zatímco external_cookie lze použít ke spojování tabulek *_match s tabulkami customer-owned, veškeré agregace single-user by měly explicitně seskupovat podle sloupce user_id, ne podle sloupce external_cookie.

Příklad agregační funkce:

WITH user_paths AS (
  # Grouping by user_id, no noise needed, all functions allowed
  SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;

Příklad analytické funkce:

WITH events AS (
  # Partitioning by user_id, no noise needed, all functions allowed
  SELECT
    campaign_id,
    ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
  FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;

Paralelní agregace

Do každé agregace s více uživateli je šum přidán nezávisle. Lze provést několik takových agregací v jednom příkazu a jejich výsledky sloučit do jedné tabulky pomocí JOIN nebo UNION.

Příklad:

WITH result_1 AS (
  # Noise applied here to num_impressions
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
  GROUP BY 1
), result_2 AS (
  # Noise applied here to num_clicks
  SELECT campaign_id, COUNT(*) AS num_clicks
  FROM adh.google_ads_clicks
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

V režimu kontroly rozdílů by tento postup byl podporován také, měli byste se mu však vyhýbat. Při použití šumu ho lze bez problému využít, protože doplnění šumu do každé z paralelních agregací a jejich filtrování probíhají nezávisle.

Propojování agregovaných dat s neagregovanými

Poznámka: Do každé agregace je šum přidáván nezávisle, takže součtové hodnoty nemusejí odpovídat. V tomto případě nemusejí součtové hodnoty imps pro dané campaign_id odpovídat příslušné hodnotě campaign_imps.

Služba Ads Data Hub podporuje pouze analytická okna rozdělující data podle user_id. Toto omezení se běžně obchází tak, že jsou tyto výsledky samostatně agregovány, spojeny se sebou samými a poté znovu agregovány. Takové dotazy jsou v režimu šumu podporovány a často fungují lépe, než by fungovaly v režimu kontroly rozdílů. protože je požadavek na ochranu soukromí vyřešen ve dřívější fázi celého procesu.

Příklad:

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

Režim šumu nepovoluje reagregaci agregovaných výsledků, jako je AVG(campaign_imps).

---

Nepodporované typy dotazů

V této části najdete dotazovací metody, které v dotazech s přidáváním šumu podporovány nejsou.

Dotazy zahrnující dnešek

Dotazy režimu šumu nepodporují dotazování na data aktuálního dne. (Toto není doporučováno v režimu kontroly rozdílů.) Aktuální datum nelze u dotazů s přidáváním šumu vybrat.

Opakované výsledky

V režimu šumu služba Ads Data Hub omezuje, jak často můžete opakovat jednu agregaci. Pokud těchto limitů dosáhnete, ztratí vaše dotazy v režimu šumu přístup k často dotazovaným datům v souboru dat. Níže uvedené příklady tento princip ilustrují.

K opakování dotazu dochází, když je stejný dotaz spuštěn několikrát se stejnými nebo vysoce podobnými parametry včetně překrývajících se období. Vyhnout se tomu můžete tak, že použijete data, která jsou již exportována v projektu BigQuery.

Jestliže se dvě úlohy dotazují na překrývající se období a v důsledku toho provádějí stejné výpočty na stejných uživatelích, může to být považováno za opakování. Například níže uvedený dotaz spuštěný s překrývajícími se obdobími vytváří repetici, protože rozděluje podle data:

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

V tomto případě byste dotaz měli spustit na obdobích, která se nepřekrývají.

Další možná repetice nastává, když jsou data do určité míry nezávislá na datu. Níže uvedený dotaz spuštěný pro překrývající se období povede k repetici, jestliže obě úlohy pokrývají celé období kampaně:

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

V tomto případě byste dotaz měli spustit jen jednou, protože výsledek se nemění.

K opakování agregace dochází, jestliže je stejná agregace v rámci jednoho dotazu opakována několikrát.

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

V tomto případě byste měli jednu z opakujících se agregací odstranit.

Za repetici jsou považovány i agregace, jejichž syntaxe se sice liší, ale počítá stejnou hodnotu. Jinými slovy, pokud je hodnota condition1 a condition2 pro všechny uživatele s určitou hodnotou parametru key stejná, obsahuje níže uvedený dotaz repetici:

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

Pokud používáte podmínky, které jsou pro některé skupiny uživatelů velmi podobné, může být vhodné přepsat dotaz tak, aby obsahoval pouze jeden příkaz COUNT.

K duplikaci řádků dochází, když je tabulka služby Ads Data Hub spojena s tabulkou služby BigQuery tak, že každý řádek z tabulky Ads Data Hub odpovídá několika řádkům v tabulce BigQuery. Například níže uvedený dotaz způsobí repetici, pokud tabulka bq_table obsahuje více řádků se stejným ID kampaně:

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

V tomto případě byste měli dotaz upravit tak, aby tabulka bq_table obsahovala pouze jeden řádek na každou hodnotu spojovacího klíče (což je v tomto případě campaign_id).

Stejný efekt může mít i konvertování pole z tabulky Ads Data Hub na skupinu řádků, jestliže většina uživatelů má v tomto poli stejné hodnoty:

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

Další doporučené postupy pro dotazy

Přímá opakovaná agregace

Šum je přidán do první úrovně agregace s více uživateli, kterou dotaz provádí. Dotazy s více úrovněmi agregace jsou zablokovány:

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

V zájmu co nejlepších výsledků agregace s přidáním šumu počítejte všechny operace s více uživateli v jediné agregaci. Například využijte funkci SUM událostí, spíše než funkci SUM dočasných výpočtových hodnot. Je možné přepsat dotaz tak, aby došlo k reagregaci agregátů se šumem, ale výsledné agregáty mohou mít mnohem vyšší šum.

Pokud je to nevyhnutelné, můžete dotaz přepsat tak, aby místo toho exportoval výsledky přímo z první vrstvy. Jestliže to chcete udělat v jediné úloze beze změn výsledků skriptu, vytvořte dočasnou tabulku (nebo tabulku exportovanou do projektu BigQuery) se syntaxí OPTIONS(privacy_checked_export=true). Například:

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

Další informace o dočasných tabulkách

Když je první úroveň agregace z hlediska kontrol ochrany soukromí příliš podrobná, zvažte přepsání dotazu agregacemi na úrovni uživatelů. Pokud to není možné, není tento dotaz v režimu šumu podporován.

Nepropojená ID uživatelů

Dotazy v režimu šumu nesmí do jedné řádky slučovat data od různých uživatelů vyjma případu, kdy dochází k agregaci s přidáním šumu. Jestliže tedy chceme explicitně spojovat podle sloupce user_id, musíme spojit neagregovaná data ze služby Ads Data Hub.

Tento dotaz nespojuje explicitně podle sloupce user_id, což způsobí chybu ověření:

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)

Lze to napravit úpravou příkazu USING tak, aby explicitně obsahoval user_id, tedy například USING(impression_id, user_id).

Toto omezení se vztahuje pouze na spojování tabulek ze služby Ads Data Hub (s výjimkou tabulek dimenzí). Nevztahuje se na tabulky vlastněné zákazníkem. Toto je například povoleno:

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

Propojení mezi Ads Data Hub a BigQuery

Aby agregace se šumem dobře fungovala, vyžaduje identifikátory uživatelů. Zákazníkem vlastněná data ve službě BigQuery žádné identifikátory uživatelů nemají, takže je nelze sloučit v rámci agregace s přidáním šumu, aniž by byla spojena s tabulkou služby Ads Data Hub.

Tento dotaz způsobí chybu ověření:

SELECT COUNT(*) FROM (
  SELECT 1 FROM adh.google_ads_impressions
  UNION ALL
  SELECT 1 FROM bigquery_project.dataset.table
)

Jestliže ho chcete opravit, buď spojte tabulku BigQuery tak, aby rozšiřovala data ze služby Ads Data Hub a nikoli sloučená data, nebo data oddělte a agregujte každý zdroj samostatně.

Slučovat několik tabulek Ads Data Hub obsahujících data o uživatelích nebo několik zákazníkem vlastněných tabulek BigQuery je v pořádku, nelze však tyto postupy kombinovat.

Spojení zprava mezi Ads Data Hub a BigQuery

Vnější spojení se zákazníkem vlastněnými daty může způsobit vznik řádků s chybějícími identifikátory uživatelů, takže pak šum nefunguje správně.

Oba tyto dotazy způsobí chyby ověření, protože umožňují vznik řádků, u kterých neexistuje shoda a ve kterých chybí identifikátory uživatelů na straně služby Ads Data Hub:

SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)

Pokud by bylo pořadí tabulek opačné, obě tato spojení by fungovala.

Souhrn odfiltrovaných řádků

Specifikace souhrnu odfiltrovaných řádků není v režimu šumu podporována. Tato funkce je při použití šumu ve většině případů zbytečná díky menšímu rozsahu filtrování a tomu, že nedochází k filtrování způsobenému kontrolou rozdílů.

Pokud ve výsledku se šumem zaznamenáte významné filtrování dat, zvětšete rozsah agregovaných dat. Můžete provést paralelní agregaci s celým souborem dat, abyste mohli porovnat odhad celku, například:

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

Celkový počet obsahuje nezávisle přidaný šum a součet celkových hodnot nemusí odpovídat. Celkový počet však bývá přesnější než součet řádků obsahujících šum.

Tabulky vytvořené v jiném režimu

Neexportované tabulky lze ve službě Ads Data Hub používat pouze ve stejném režimu ochrany soukromí, ve kterém byly vytvořeny. Není možné vytvořit tabulku v normálním režimu agregace a pak ji používat v režimu šumu ani naopak (pokud tabulku nejprve neexportujete do služby BigQuery).