🔸 🤞 🏦 Cara mengatasi kesalahan saat membangun pelaporan di Power BI dan sampai pada pembangunan sistem unggah untuk data besar 🙌🏽 👃🏼 🏴󠁧󠁢󠁳󠁣󠁴󠁿

Di balik dashboard Power BI yang indah dan mudah dipahami, seringkali persiapan dan penambangan data selama berminggu-minggu. Terutama ketika datang untuk membangun pelaporan BI yang bermanfaat dalam organisasi besar dengan volume lalu lintas puluhan juta pengunjung setiap bulan.

Dalam artikel ini, saya ingin menggambarkan sejumlah aspek negatif yang saya temui ketika membangun pelaporan BI berdasarkan data dari sistem analisis web di sejumlah perusahaan (perwakilan besar e-commerce Rusia, perusahaan asuransi, dll.). Artikel ini tidak bertujuan untuk membuat anti-iklan, atau sebaliknya, iklan alat atau keputusan tertentu. Ini disiapkan untuk membantu menghindari kemungkinan momen negatif bagi pengguna lain dan menunjukkan opsi untuk solusi.

Penolakan

Saya berbicara tentang sejumlah besar data dan menunjukkan contoh pengunggahan dan pengambilan sampel dari Google Analytics 360. Pada proyek-proyek dengan sejumlah kecil data, kesulitan seperti itu mungkin tidak ada. Saya memenuhi semua masalah yang diidentifikasi dalam praktik dan dalam artikel yang saya jelaskan hanya pengalaman saya dalam memecahkan - masalah Anda bisa sangat berbeda.

Konektor ke Yandex.Metrica

Yandex.Metrica memiliki kondisi pengambilan sampel yang lebih ringan dan antarmuka yang intuitif dibandingkan dengan Google Analytics. Oleh karena itu, banyak pemasar lebih suka Yandex.Metrica dan membangun pelaporan BI tentang pengunggahan data dari sana. Untuk melakukan ini, gunakan konektor Maxim Uvarov. Metode ini tidak aman dan tidak memungkinkan pemrosesan permintaan yang kompleks.

Perusahaan besar memerlukan jaminan bahwa informasi rahasia tidak akan jatuh ke tangan pencela, dan indikator keuangan hanya akan digunakan untuk pemangku kepentingan dan secara eksklusif di dalam perusahaan.

Perkecil besar pertama adalah bahwa untuk menggunakan konektor, di Power BI Anda harus mengaktifkan pengaturan "Abaikan tingkat privasi", jika tidak maka itu tidak akan berfungsi.

Dengan demikian, data rahasia dapat jatuh ke tangan pengguna yang tidak sah. Ini dikonfirmasi oleh kutipan dari Bantuan Power BI.

Koneksi data bersifat anonim. Namun, tidak ada otorisasi atau memeriksa izin untuk menggunakan data ini untuk para pengguna yang benar-benar diizinkan.

Agar konektor ini berfungsi, Anda harus mendapatkan token akses otomatis. Deskripsi konektor menyediakan tautan tentang cara memberi akses aplikasi ke akun Anda.

Bahkan, aplikasi pihak ketiga akan mendapatkan akses ke akun Anda. Tidak ada yang memberikan jaminan untuk keamanan data Anda.

Kekurangan kedua adalah bahwa Yandex.Metrica API tidak dapat memproses data dalam jumlah besar pada proyek-proyek besar, dan sebagai akibatnya, konektornya juga menolak untuk bekerja dengan pertanyaan kompleks pada data Yandex.Metrica mentah - itu tidak membongkar mereka.

Misalnya, Anda perlu mengunggah data selama setahun, tanpa filter yang rumit. Konektor membuat kesalahan: “Permintaan terlalu rumit. Harap kurangi penspasian tanggal atau pengambilan sampel. "

Tentu saja, ini adalah terjemahan dari kesalahan Yandex.Metrica API itu sendiri. Namun, dalam hal ini, kami tidak punya pilihan untuk mengunduh data dengan rincian menurut bulan atau hari - misalnya, untuk menggilir data untuk setiap bulan dan menggabungkannya ke dalam satu set data yang mengatasi kesalahan API.
Jika Anda mengurangi periode secara signifikan, maka API memungkinkan Anda untuk memompa data, tetapi ini hanya sebagian kecil dari yang kami butuhkan.

Untuk membuat laporan besar, pembongkaran untuk waktu yang singkat tidak praktis dan tidak nyaman. Dalam praktiknya, Anda sering perlu membongkar melalui corong situs terbuka yang kompleks dengan banyak kunjungan per hari. Terutama ketika menggunakan segmen kunjungan yang rumit, praktis tidak mungkin untuk mengunggah data yang diperlukan.

Sekalipun Anda dapat memuat data, bukan fakta bahwa Anda dapat mengunggah ke model data untuk membangun pelaporan itu sendiri, karena berbagai kesalahan pemuatan muncul setiap saat. Untuk beberapa alasan, bahkan dengan tabel yang biasanya dimuat, kesalahan terjadi.

Agar semua pemangku kepentingan dalam perusahaan dapat menggunakan laporan yang dibangun pada konektor Yandex.Metrica API, Anda harus menerbitkan laporan di Layanan PowerBI. Dalam hal ini, tingkat privasi juga harus diabaikan.

Ketika visualisasi dikonfigurasikan dan laporan dipublikasikan di cloud Microsoft, konektor akan menampilkan kesalahan kueri gabungan dan tidak akan diperbarui melalui Layanan Power BI - Anda tidak akan dapat mengonfigurasi pembaruan terjadwal laporan Anda. Kesalahan terjadi ketika salah satu kueri, yang membentuk tabel unggah akhir, berisi logika kerja simultan dengan kueri eksternal dan internal.

Dalam kesalahan,

tabel "Fungsi dipanggil" hanya ditunjukkan: Tabel ini diperoleh karena fungsi PQYM, yang bekerja dengan sumber data eksternal - Yandex.Metrica API. Mekanisme pembaruan pelaporan di Power BI tidak berfungsi dan meminta untuk mengulang kombinasi pertanyaan. Ini karena tautan internal dari satu permintaan untuk terhubung ke permintaan eksternal, serta karena struktur fungsi itu sendiri.

Kami memutuskan untuk tidak menggunakan konektor seperti itu saat membuat pelaporan dan beralih ke membongkar data dari Yandex.Metrica API melalui skrip Python, lebih lanjut tentang ini nanti dalam artikel.

Konektor Google Analytics

Untuk membuat pelaporan pada data Google Analytics (kami berbicara tentang pengunduhan langsung dari sistem analitik), ada juga konektor Maxim Uvarov.

Di sini Anda juga harus mengatur "Mengabaikan tingkat privasi". Akses ke API sistem analitik Anda, yang berisi data penjualan online, terjadi pada koneksi anonim.

Menurut instruksi, sekali lagi Anda harus membuka akses ke aplikasi pihak ketiga, hanya untuk akun Google, yang berisi ancaman terhadap privasi data Anda.

Anda dapat menulis ulang beberapa data dalam konektor itu sendiri dan mulai menggunakannya untuk aplikasi Anda sendiri. Untuk melakukan ini, daftarkan "ID Klien OAuth 2.0" di cloud.google.com, dapatkan token akses dan masukkan kunci akses yang diperlukan dalam mekanisme kerjanya. Tetapi bahkan tindakan ini tidak akan membantu dalam memerangi pengambilan sampel dan memperbarui pelaporan Anda.

Setiap kali Anda menyentuh data agregat API Google Analytics, kami akan selalu menemukan pengambilan sampel.

Konektor memiliki opsi unloading satu hari, tetapi meskipun tidak selalu menyimpan. Indikator pengambilan sampel yang terpasang pada konektor menunjukkan bahwa indikator itu ada di sana bahkan dalam satu hari.

Misalnya, data sesi yang dirinci menurut Tahap Belanja tidak dapat diunggah tanpa sampel pada jumlah data seperti itu. Ini akan menyebabkan kesalahan besar dalam data dan tindakan saat membuat laporan, terutama ketika perlu untuk menghitung konversi transisi secara akurat dari satu langkah ke langkah lain, atau untuk mengunggah data pada corong dengan struktur segmen yang kompleks.

Bahkan jika kehilangan data tidak penting bagi Anda, Anda masih tidak dapat mengonfigurasi pembaruan terjadwal laporan Anda melalui Layanan Power BI.

Kesalahan yang sama dari mekanisme kerja mengganggu, hanya fungsi PQGA.

Kami juga menolak untuk bekerja dengan konektor ini.

Konektor Asli Google Analytics

Terkadang Google dan Microsoft membuat konsesi satu sama lain: Power BI out of the box memiliki konektor Google Analytics standar. Sayangnya, tidak ada opsi seperti itu untuk Yandex.Metrica.

Mekanisme untuk bekerja dengan Google Analytics API lebih mudah diterapkan di sini daripada di konektor Maxim Uvarov, tetapi saat mengunduh sejumlah besar indikator, data terlalu sampel. Angka berulang dalam tangkapan layar adalah data sampel.

Anda dapat menghindari pengambilan sampel jika Anda menurunkan tabel mini yang dipecah hanya berdasarkan tanggal dan satu indikator saja. Misalnya, tanggal, jumlah sesi, dan jenis perangkat. Dan kemudian dari tabel ini untuk mengumpulkan pelaporan yang diperlukan.

Jika Anda tidak memiliki jutaan lalu lintas, ini dapat membantu. Namun, pelaporan tidak akan informatif dan dengan keterbatasan skalabilitas: karena banyaknya tabel mini dalam model data, sulit untuk membuat hubungan di antara mereka. Ini memberlakukan pembatasan pada pembuatan filter dan irisan.

Anda dapat menulis ulang konektor standar dan memaksanya untuk mengunggah data setiap hari, sementara data akan mendekati angka nyata di antarmuka GA, tetapi Anda tidak akan bisa menghindari pengambilan sampel.

Menurut pengamatan saya, dalam rincian sesi Stage Shopping, tidak ada satu konektor pun yang dapat mengunggah data secara normal tanpa mengambil sampel data dalam jumlah besar.

Pada konektor standar, Anda tidak dapat mengubahsuaikan tanggal pengunduhan. Semua itu hanyalah pilihan parameter dan metrik dari API Google Analytics yang diatur dalam folder.

Konektor ini cocok untuk proyek Internet kecil dan menengah dengan sedikit lalu lintas. Di sini, situasi serupa muncul dengan memperoleh data dari Yandex.Metrica. Semua informasi yang diperlukan tanpa kehilangan keakuratan hanya dapat diunduh secara langsung melalui API menggunakan skrip atau layanan streaming data khusus - lebih lanjut tentang ini nanti dalam artikel.

Sticks in Wheels oleh Google

Baru-baru ini, kami melihat kunci aneh - ketika mencoba mengonfigurasi pembaruan untuk konektor "asli" ke Google Analytics, kesalahan otorisasi muncul melalui akun Google di antarmuka Layanan BI Power.

Kami mencoba mencari tahu dari Google apa yang harus dilakukan dalam situasi seperti itu dan bagaimana "menghapus" reputasi akun, tetapi upaya kami gagal. Kami mencoba mendaftarkan akun baru dan masuk melalui berbagai perangkat - Google memblokir upaya otorisasi apa pun.

Sekitar sebulan setelah pemblokiran, kami masih berhasil masuk melalui akun yang sama, tetapi kejadian seperti itu dapat sangat mengganggu pelepasan pelaporan BI yang diperlukan secara tepat waktu dan menempatkan pelanggan dalam posisi yang canggung. Segera setelah kunci, kami mulai mencari jalan keluar yang mungkin dari situasi itu. Untuk menghindari kunci tak terduga, kami memutuskan untuk menciptakan lingkungan terkontrol kami sendiri dengan data yang diperlukan untuk pelaporan BI.

Opsi solusi

Dapatkan pelaporan BI yang diperlukan untuk organisasi menengah dan besar, dan bahkan tanpa sampling adalah mungkin. Tetapi Anda perlu mencoba sedikit dan memilih salah satu dari beberapa cara.

Anda dapat menggunakan layanan yang sudah jadi untuk streaming data. Tujuan utama mereka adalah mengunggah data dari sistem analitik, berbagai sistem periklanan, CRM, dan layanan lainnya ke penyimpanan apa pun. Nyaman, cepat dan praktis, tetapi tidak gratis. Pada volume besar data atau data dengan banyak sumber, jumlahnya nyata.

Layanan paling terkenal:

Masing-masing sistem ini memungkinkan Anda untuk mengonfigurasikan streaming harian data non-sampel dari sistem analisis web (Yandex.Metrics dan Google Analytics) ke basis data (misalnya, BigQuery, Database SQL Azure, Microsoft SQL Server atau ClickHouse) untuk terhubung melalui Power BI dan membuat laporan.

Jika alat yang terdaftar terlalu mahal untuk perusahaan, Anda dapat mencoba menerapkan sistem unggah data Anda dan menggunakan Power BI + Python + Server Cloud Apa Saja (atau Yandex.Cloud) + PostgreSQL. Ini adalah metode yang kami gunakan saat membangun pelaporan BI.

Skema Interaksi Sistem:

Skema kerja semacam itu menyediakan pelestarian, otonomi, dan agregasi data yang diperlukan. Setelah membuat skema semacam itu satu kali, Anda tidak perlu menghabiskan waktu mengumpulkan informasi - semuanya ada di repositori, Anda hanya perlu terhubung dan mulai membuat laporan tentang Power BI.

Skrip python "menarik" semua data sesuai dengan API dari sumber yang diperlukan, menulis ke database atau membongkar bentuk (misalnya, dalam format csv). Skrip untuk mengunggah dari API dan memuat ke dalam basis data layak mendapat artikel terpisah, dan suatu hari nanti saya akan menulisnya.

Tentu saja, ada banyak templat dan solusi siap pakai di Internet, tetapi untuk penskalaan selanjutnya perlu mengetahui kebutuhan individu dari sistem di mana skrip untuk pembongkaran dibuat.

Data ditulis ke database yang dibuat sebelumnya dan dikonfigurasi - dalam kasus kami, PostgreSQL. Script memompa data untuk setiap hari dan menuliskannya ke tabel sesuai dengan jadwal. Mereka berada di server cloud di bawah kendali kami atau di bawah kendali layanan keamanan TI klien.

Ada sejumlah besar perusahaan yang menyediakan layanan penyimpanan cloud. Berdasarkan preferensi pribadi, Yandex . Cloud terpilih .

Keuntungan dari Yandex.Cloud:

Konfigurasi yang mudah dan penyewaan server dengan PostgreSQL yang sudah diinstal.
Dokumentasi yang luas dalam bahasa Rusia, yang dinyatakan dengan jelas dan memungkinkan Anda dengan cepat mempelajari cara menggunakan layanan ini.
Manajemen server yang nyaman.
Dukungan cepat dari spesialis.
Fleksibilitas dari berbagai pengaturan dan tarif peralatan: tidak ada yang memaksakan paket konfigurasi yang sudah jadi, Anda memilih sendiri konfigurasi peralatan Anda, plus Anda dapat langsung memesan preset dari basis data apa pun.

Unggahan yang dihasilkan ditulis ke database PostgreSQL. Database ini dipilih karena merupakan DBMS objek-relasional (bekerja dengan array multidimensi dan dukungan JSON dari "kotak" - untuk struktur data yang kompleks harus dimiliki). Ini fleksibel, dapat diandalkan, gratis, dan juga memiliki komunitas dukungan yang besar.

Power BI memiliki konektor langsung bawaan di PostgreSQL. Pada koneksi pertama, Anda perlu menginstal Npgsql tambahan . Power BI memberi tahu Anda tentang hal ini dan menyediakan tautan.

Untuk mengonfigurasi pembaruan laporan saat menggunakan penyimpanan cloud, Anda harus mengonfigurasi Power BI Gateway . Diperlukan untuk mengonfigurasi pembaruan pelaporan BI dan memastikan keamanan data rahasia ketika mentransfernya dari database, yang harus ditempatkan di sirkuit TI internal organisasi Anda, atau di server cloud yang aman.

Gateway menyediakan transfer data yang cepat dan aman antara penyimpanan data yang terletak di jaringan internal organisasi dan layanan cloud Microsoft. Transfer data antara Power BI dan gateway aman, dan semua kredensial yang disediakan oleh administrator gateway dienkripsi untuk melindungi informasi di cloud dan didekripsi hanya di komputer gateway.

Setelah mengunduh Power BI Gateway dan meluncurkannya, kotak dialog muncul.

Untuk mendaftar dan mengoperasikan gateway, kredensial layanan cloud Layanan Power BI diperlukan.

Setelah semua pengaturan, jendela tentang gateway yang berfungsi akan muncul. Selanjutnya, Anda perlu membuat pengaturan tambahan.

Alternatif yang lebih sederhana untuk menyesuaikan PostgreSQL adalah Google BigQuery. Power BI memiliki konektor bawaan di Google BigQuery. Dalam hal ini, perlu mengikuti prinsip "tujuh kali untuk menghitung biaya, satu kali untuk memenuhi permintaan."

BigQuery dapat digunakan secara gratis selama satu tahun, hanya dengan mengikat kartu bank berdasarkan perjanjian untuk menggunakan layanan ini. Uang setelah batas waktu tanpa sepengetahuan Anda tidak akan didebit. Selanjutnya tarif - sesuai dengan tarif sistem itu sendiri, tetapi dengan beberapa "plus" yang menyenangkan.

Jika data yang diunduh dari sistem Anda tidak mencapai 10 GB per bulan (!), Tidak akan ada biaya untuk mengunduh.

Jika pemrosesan data bulanan tidak melebihi 1 TB, tidak ada biaya yang dikenakan untuk ini. Jika lebih, maka $ 5 untuk setiap pengobatan 1 TB.

Jika Anda perlu menyimpan lebih dari 10 GB per bulan, setiap gigabyte berikutnya akan dikenakan biaya $ 0,010.

Tarif dijelaskan lebih terinci di halaman BigQuery.

Ringkasan

Jika Anda memerlukan data dari berbagai sistem analitik, dan pada saat yang sama, keselamatan, keamanan, agregasi berkelanjutan, kegunaan dan kurangnya pengambilan sampel merupakan hal mendasar bagi Anda, Anda memiliki dua cara.

Yang pertama adalah layanan streaming. Mereka mudah digunakan, mereka memiliki dukungan teknis yang berkelanjutan dan integrasi siap pakai dengan gudang data.

Kekurangan:

Biaya nyata pada sejumlah besar data.
Jenis integrasi yang disediakan terbatas.
Proses yang tidak terkendali di sisi penyedia layanan streaming untuk bekerja dengan informasi Anda.

Yang kedua adalah aliran pengunggahan data dan agregasi sendiri. Dapat diukur, dikendalikan, dengan keamanan data. Mungkin terlihat rumit dan memakan waktu untuk diterapkan. Jika perusahaan membutuhkan organisasi pelaporan BI yang efektif, skalabilitas lebih lanjut dan keamanan data, maka opsi ini adalah yang paling dapat diterima.

Semua orang yang hanya memikirkan pelaporan BI penuh perlu menambahkan moto “Akumulasi, susun, dan lindungi data ini dari kaum muda” ke dalam budaya perusahaan. Tidak ada yang lebih baik daripada database toleransi kesalahan lengkap dengan backup reguler dan dengan hak yang berbeda untuk menggunakannya untuk berbagai kategori pemangku kepentingan.

Anda perlu mengakumulasi, menyusun, dan mengumpulkan data Anda dari sistem analitik, dan dari aplikasi seluler, dan dari layanan klien lainnya. Semua ini di masa depan akan membantu menganalisis audiens dan produk Anda di bagian mana pun. Informasi dan data sekarang menguasai dunia dan kadang-kadang lebih mahal daripada uang.

Bagaimana menerapkan pendekatan yang dijelaskan dalam artikel untuk mentransfer data analitik ke database PostgreSQL menggunakan skrip Python dan detail implementasi, saya akan membahas dalam artikel berikut.

Cara mengatasi kesalahan saat membangun pelaporan di Power BI dan sampai pada pembangunan sistem unggah untuk data besar