Looker Studio palasi Data Studio -nimeen huhtikuussa 2026. Koontinäyttö ei takaa reaaliaikaisia tietoja tai luottamuksellista jakamista.
Vertaa ilman eron liioittelua
Kuvitteellinen esimerkki: A on 40 ja B 50, lisäys 10 yksikköä ja 25 % A:sta. Nollasta alkavien palkkien pituussuhde on 1,25. Kun alku on 38, pituudet ovat 2 ja 12, suhde 6: ero näyttää suuremmalta. Luvut eivät ole asiakastuloksia.
Tarkista tuoreus, pääsy ja teksti
Tuoreus riippuu lähteistä, yhdistimistä ja välimuisteista; näytön päivitys ei pakota uutta keruuta. Power BI:n Julkaise verkkoon tekee raportin julkiseksi ilman tunnistautumista, myös taustatietoja: se ei sovi luottamuksellisille tiedoille. Anna arvot ja selitys tekstinä, älä luota vain väriin.
| Kohta | Todellinen arvo | Pituus lähtötasosta 38 |
|---|---|---|
| A | 40 | 2 |
| B | 50 | 12 |
Lähteet ja tarkistus
- Google — Data Studio name, April 2026
- Google — Data freshness
- Microsoft — Publish to web
- Government Analysis Function — Bar charts
- W3C WAI — Complex images
Kaavioiden tulisi paljastaa datan laatu.
Kojelaudan selkeys ulottuu kaavion valintaa pidemmälle. Päivitysajan, yksikön, populaation ja lopullisen ajanjakson tulisi olla näkyvissä; puuttuvat arvot eivät saa hiljaa nollautua. Vertailujen tulisi säilyttää määritelmät ja merkitä kokoelman katkokset.
- Näytä kattavuus ja tuoreus ratkaisevien lukujen lähellä.
- Testaa nolla, puuttuva ja osittain päivitetty data.
- Täsmäytä aggregaatit kontrollilähteen kanssa mallimuutosten jälkeen.
Ensisijainen lähde: Google SRE — Data Processing Pipelines. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Aikavyöhykkeet ja myöhäiset tapahtumat
Raportin ajanjakso riippuu tapahtuma-ajasta ja sulkemissäännöstä.
- Kirjaa tapahtuma-aika, vastaanottoaika ja liiketoiminnan aikavyöhyke erikseen. Kuvitteellisessa esimerkissä 23:30 UTC on seuraavan päivän 01:30 kiinteällä UTC+02:00-siirtymällä. PostgreSQLin aikavyöhykkeen sisältävä aikaleima ei säilytä alkuperäistä vyöhykkeen nimeä.
- Käytä mukaan kuuluvaa alkua ja pois jätettävää loppua. Muodosta rajat liiketoiminnan vyöhykkeessä ennen UTC-muunnosta. Testaa kesäaikaan siirtyminen, kuukauden vaihde ja päivämäärä ilman kellonaikaa; paikallista päivää ei voi aina korvata 24 tunnilla.
- Määritä hyväksyttävä viive ja raportin sulkemisaika. Toista sama tunniste erottaaksesi uuden tapahtuman kaksoiskappaleesta. Säilytä julkaistu versio ja kirjaa korjauksen vaikutus; vesileima on arvio saapumisesta eikä lupaus kaikkien tietojen saapumisesta.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}Odotettu päätös
Tapahtuma kuuluu annetussa vyöhykkeessä 9. lokakuuta. Säilytä myös UTC-hetki.
Tarkistusmenettely
- Määritä raportin vyöhyke ja viitehetki.
- Toista tapahtuma lähellä keskiyötä.
- Säilytä UTC, paikallispäivä ja katkaisusääntö. Sisällytä kellonsiirron monitulkintainen paikallisaika; säilytä UTC-siirtymä ja aikavyöhyke sen sijaan, että päättelisit hetken.
Voiko vastaanottopäivää käyttää tapahtumapäivänä?
Vain jos raportin määritelmä sitä edellyttää. Säilytä molemmat ajat ja selitä myöhäisten tapahtumien käsittely.
Ensisijainen lähde: PostgreSQL — Date/time types. Aiheeseen liittyvä menetelmä: lue käytännön opas.