មេរៀនប្រើប្រាស់ Metabase៖ ជួយឱ្យសហការីដែលមិនចេះ SQL អាចទាញយកទិន្នន័យដោយខ្លួនឯងបាន

ចាប់ពីការដំឡើងដោយខ្លួនឯង ការតភ្ជាប់មូលដ្ឋានទិន្នន័យ ការបង្កើតផ្ទាំងគ្រប់គ្រងដំបូង រហូតដល់របៀបប្រើប្រាស់មុខងារសួរសំណួរ AI ។ ថែមទាំងពន្យល់យ៉ាងច្បាស់អំពីបញ្ហាលាក់កំបាំងនៃការគិតថ្លៃតាមចំនួនអ្នកប្រើប្រាស់ ដែលការฝັງ (Embed) ឱ្យអតិថិជនមើលក៏ត្រូវគិតលុយដែរ ដែលរឿងនេះមនុស្សជាច្រើនដឹងនៅពេលទទួលបានវិក្កយបត្រ។

មេរៀនរបៀបប្រើប្រាស់ Metabase៖ ឱ្យបុគ្គលិកដែលមិនចេះ SQL អាចទាញយកទិន្នន័យដោយខ្លួនឯង

ម៉ោងដប់ព្រឹក គ្រុបឆាតរបស់ក្រុមហ៊ុនອີកូមើនេសមួយក្នុងទីក្រុងតៃប៉ិ មានអ្នកគ្រប់គ្រងផ្នែកទីផ្សារបានសួរថា៖ «តើខែមុនមានអតិថិជនបញ្ជាទិញតាម LINE ប៉ុន្មាននាក់?» ពេលឃើញសំណួរនេះ វិស្វកររូបនោះបានដកដង្ហើមធំ បើក Database មកសរសេរ SQL អស់ពេលប្រហែលប្រាំពីរនាទី ទើបផ្ញើរូបភាព Screenshot ឆ្លើយតបទៅវិញ។ ដល់ម៉ោងបីរសៀល មនុស្សដដែលនោះបានសួរម្ដងទៀតថា៖ «ចុះបើធៀបនឹងខែដូចគ្នាកាលពីឆ្នាំមុនវិញ?»

វដ្ដបែបនេះកើតឡើងជារៀងរាល់ថ្ងៃនៅក្នុងសហគ្រាសខ្នាតតូច និងមធ្យម។ បញ្ហាមិនមែនមកពីវិស្វករមិនចង់ជួយនោះទេ ប៉ុន្តែការពិតការងារនេះ មិនគួររំខានដល់វិស្វករទាល់តែសោះ។ នេះហើយជាអ្វីដែល Metabase ចង់ដោះស្រាយ។

ഇത് എന്താണ് (តើវាជាអ្វី?)

Metabase គឺជាប្រភពកូដបើកចំហ (Open-source) នៃឧបករណ៍ Business Intelligence (BI) មួយ។ អ្នកគ្រាន់តែភ្ជាប់វាទៅនឹង Database របស់ក្រុមហ៊ុន បុគ្គលិកដែលមិនសូវជំនាញខាងបច្ចេកទេសក៏អាចចុចបញ្ជាដើម្បីទាញយកទិន្នន័យ រក្សាទុកជា "Question" និងផ្គុំសំណួរទាំងនោះទៅជា Dashboard ផងដែរ។ លើសពីនេះ មុខងារជំនួយ AI Question និងការបង្កើតកូដ SQL ដោយស្វ័យប្រវត្តិតามរយៈការសន្ទនាដែលបានបន្ថែមក្នុងរយៈពេលពីរឆ្នាំចុងក្រោយនេះ ធ្វើឱ្យយើងអាចប្រើប្រាស់ភាសាសាមញ្ញដើម្បីរៀបរាប់ពីតម្រូវការបានយ៉ាងងាយស្រួល។

លក្ខណៈពិសេសដ៏អស្ចារ្យបំផុតរបស់វាគឺ ខ្សែកោងនៃការរៀនសូត្រ (Learning Curve) គឺងាយស្រួលបំផុតបើធៀបនឹងផលិតផលស្រដៀងគ្នា។ នេះស្តាប់ទៅដូចជាពាក្យពេចន៍ផ្សាយពាណិជ្ជកម្ម ប៉ុន្តែក្នុងការអនុវត្តជាក់ស្តែងវាខុសគ្នាឆ្ងាយណាស់ ព្រោះមូលហេតុចម្បងដែលធ្វើឱ្យឧបករណ៍ BI ភាគច្រើនបរាជ័យ មិនមែនមកពីមុខងារមិនគ្រប់គ្រាន់នោះទេ ប៉ុន្តែដោយសារតែគ្មាននរណាមستخدمវាបន្ទាប់ពីដំឡើងរួច។

តើវាអាចធ្វើអ្វីបានខ្លះ?

  • ប្រើប្រាស់ចំណុចប្រទាក់ចុចដើម្បីទាញយកទិន្នន័យ ដោយមិនចាំបាច់សរសេរ SQL
  • រក្សាទុកសំណួរដែលប្រើញឹកញាប់ជា "Question" ដើម្បីដំណើរការឡើងវិញបានគ្រប់ពេល
  • ផ្គុំវាជា Dashboard និងកំណត់ពេលផ្ញើដោយស្វ័យប្រវត្តិទៅកាន់ Email ឬ Slack
  • ប្រើប្រាស់ភាសាសាមញ្ញដើម្បីសួរនាំ និងបង្កើតកូដ SQL ដោយស្វ័យប្រវត្តិ (មានសម្រាប់គ្រប់កញ្ចប់ មិនមែនសម្រាប់តែអ្នកបង់ប្រាក់នោះទេ)
  • កកំណត់ការជូនដំណឹង (Alerts) នៅពេលដែលតិន្នន័យមានភាពមិនប្រក្រតី
  • បញ្ចូល (Embed) ទៅក្នុងផលិតផលផ្ទាល់ខ្លួន ដើម្បីឱ្យអតិថិជនមើលបាន

វិធីប្រើប្រាស់៖ ពីសូន្យដល់ Dashboard ដំបូង

ជំហានទី១៖ ការដំឡើង

វិធីដែលលឿនបំផុតគឺប្រើប្រាស់ Docker ជាមួយនឹងคำสั่งមួយជួរ៖

bash
docker run -d -p 3000:3000 --name metabase metabase/metabase

ពេលដែលវាដំណើរការហើយ សូមបើក http://localhost:3000 ហើយធ្វើតាមមគ្គុទ្ទេសក៍ដំឡើងជាការស្រេច។ កំណែ Open-source គឺមានមុខងារពេញលេញ និងមិនកំណត់ចំនួនអ្នកប្រើប្រាស់ ការសាងសង់ដោយខ្លួនឯងគឺឥតគិតថ្លៃទាំងស្រុង។

សម្រាប់បរិយាកាសការងារជាក់ស្តែង (Production) មានរឿងពីរដែលត្រូវយកចិត្តទុកដាក់៖ ទីមួយ តាមលំនាំដើមវាប្រើប្រាស់ H2 Database ខាងក្នុងដើម្បីរក្សាទុកការកំណត់របស់ Metabase ដូច្នេះ សម្រាប់បរិយាកាសការងារពិតប្រាកដ ចាំបាច់ត្រូវប្តូរទៅប្រើ PostgreSQL ខាងក្រៅវិញ បើមិនដូច្នេះទេ វាងាយនឹងមានបញ្ហានៅពេលធ្វើបច្ចុប្បន្នភាព ឬប្តូរម៉ាស៊ីន។ ទីពីរ ត្រូវប្រាកដថាបានកំណត់ការสำรองទិន្នន័យ (Backup)។

ជំហានទី២៖ ភ្ជាប់ទៅកាន់ Database របស់អ្នក

បន្ថែមប្រភពទិន្នន័យថ្មីនៅក្នុងការកំណត់ ដោយបំពេញ Host, Port, ឈ្មោះ Database, ឈ្មោះអ្នកប្រើប្រាស់ និងពាក្យសម្ងាត់។ វាគាំទ្រ MySQL, PostgreSQL, SQL Server, BigQuery និងជម្រើសទូទៅផ្សេងទៀត។

គន្លឹះសំខាន់ក្នុងជំហាននេះគឺសិទ្ធិអំណាច (Permissions)។ សូមប្រាកដថាបានបង្កើត គណនីអានតែប៉ុណ្ណោះ (Read-only account) សម្រាប់ Metabase ប្រើប្រាស់ ដោយមិនត្រូវដាក់គណនី root ចូលទៅដោយសារតែភាពងាយស្រួលនោះទេ។ ឧបករណ៍ BI ត្រូវការតែការអានប៉ុណ្ណោះ ការផ្តល់សិទ្ធិសរសេរ (Write) មិនមានប្រយោជន៍អ្វីទេ គឺមានតែហានិភ័យប៉ុណ្ណោះ។

ជំហានទី៣៖ បង្កើត "Question" ដំបូងរបស់អ្នក

ចុចលើ "New → Question" ជ្រើសរើសតារាងទិន្នន័យ បន្ទាប់មកប្រើចំណុចប្រទាក់ដើម្បីកំណត់លក្ខខណ្ឌ៖ ការត្រង (ឧទាហរណ៍៖ "កាលបរិច្ឆេទបញ្ជាទិញគឺខែមុន") ការចងក្រងសង្ខេប (ឧទាហរណ៍៖ "រាប់ចំនួន") និងការបែងចែកក្រុម (ឧទាហរណ៍៖ "បែងចែកតាមប្រភព")។

នេះគឺជាចម្លើយដែលអ្នកគ្រប់គ្រងផ្នែកទីផ្សារនៅដើមអត្ថបទចង់បាន ហើយគាត់អាចកែប្រែវាទៅជាខែដូចគ្នាកាលពីឆ្នាំមុនដោយខ្លួនឯងបាន — គ្រាន់តែប្តូរកាលបរិច្ឆេទត្រងបន្តិចបន្តួច ដោយមិនចាំបាច់ពឹងផ្អែកលើវិស្វករទៀតទេ។

បន្ទាប់ពីរៀបចំរក្សាទុកជា Question រួច អ្នកអាចជ្រើសរើសប្រភេទគំនូសតាង (Chart)៖ ក្រាហ្វវាស់ (Bar chart) ក្រាហ្វបន្ទាត់ (Line chart) ក្រាហ្វរង្វង់ (Pie chart) ឬតារាង (Table)។

ជំហានទី៤៖ ផ្គុំជា Dashboard និងផ្ញើដោយស្វ័យប្រវត្តិ

បន្ថែមសំណួរដែលទាក់ទងគ្នាទៅក្នុង Dashboard តែមួយ ឧទាហរណ៍៖ "ចំណូលខែនេះ, ចំនួនការបញ្ជាទិញ, ភាគរយតាមប្រភពនីមួយៗ, ទំនិញលក់ដាច់ខ្លាំងជាងគេទាំងដប់"។ បន្ទាប់មកកំណត់ការ "Subscriptions" ដើម្បីឱ្យវាផ្ញើដោយស្វ័យប្រវត្តិទៅកាន់ប្រអប់សាររបស់អ្នកគ្រប់គ្រងរៀងរាល់ព្រឹកថ្ងៃចន្ទ។

មុខងារផ្ញើដោយស្វ័យប្រវត្តិនេះ គឺត្រូវបានមើលស្រាលខ្លាំងណាស់។ មនុស្សភាគច្រើនមិនសូវបើក Dashboard មើលដោយខ្លួនឯងទេ ប៉ុន្តែពួកគេប្រាកដជាមើល Email។ ការជំរុញទិន្នន័យទៅមុខពួកគេ គឺមានប្រសិទ្ធភាពជាងការរໍាស្រង់ឱ្យពួកគេមកស្វែងរកដោយខ្លួនឯងឆ្ងាយណាស់។

គន្លឹះកម្រិតខ្ពស់

របៀបប្រើប្រាស់ AI ក្នុងការសួរសំណួរ។ សួរសំណួរជាភាសាសាមញ្ញផ្ទាល់ថា "ចំណូលតាមឆានែលនីមួយៗកាលពីខែមុន" វាគ្ហនឹងបង្កើតកូដ SQL និងដំណើរការវា។ បទពិសោធន៍ជាក់ស្តែងគឺ៖ សំណួរងាយៗមានភាគរយត្រឹមត្រូវល្អ ប៉ុន្តែបើពាក់ព័ន្ធនឹងការ join តារាងច្រើន ឬកិច្ចការឡូជីខលស្មុគស្មាញ វាងាយនឹងខុសណាស់។ វិធីសាស្រ្តរបស់ខ្ញុំគឺប្រើវាដើម្បីបង្កើតជាសេចក្តីព្រាង (Draft) ហើយពិនិត្យមើលកូដ SQL ឡើងវិញដោយខ្លួនឯង ដែលលឿនជាងការចាប់ផ្តើមសរសេរពីសូន្យ។ ការប្រើប្រាស់ AI អាចប្រើប្រាស់សេវាកម្មផ្លូវការ (3.75 ដុល្លារក្នុងមួយលានតូខែន ចាប់ផ្តើមជាមួយអំណោយមួយលានតូខែន) ឬអាចភ្ជាប់ API Key ផ្ទាល់ខ្លួន — ជម្រើសក្រោយនេះសន្សំសំចៃជាងសម្រាប់ក្រុមដែលមានកូតា API រួចជាស្រេច។

បង្កើតគំរូទិន្នន័យ (Model)។ ប្រសិនបើឡូជីខល join ណាមួយត្រូវបានប្រើប្រាស់ម្តងហើយម្តងទៀត សូមរក្សាទុកវាជា Model ដើម្បីឱ្យសហការីអាចធ្វើការស្វែងរកនៅលើ數據集ដែលមានរបៀបរៀបរយល្អ ដោយមិនចាំបាច់រៀបចំទំនាក់ទំនងឡើងវិញរាល់ពេលនោះទេ។ នេះគឺជាជំហានគន្លឹះដែលធ្វើឱ្យបុគ្គលិកដែលមិនមែនជាអ្នកបច្ចេកទេសអាចប្រើប្រាស់វាបានពិតប្រាកដ។

ប្រើប្រាស់ការពិពណ៌នាfieldឱ្យបានល្អ។ បន្ថែមការពន្យល់ជាភាសាសាមញ្ញសម្រាប់ field នីមួយៗក្នុងការកំណត់ទិន្នន័យ ឧទាហរណ៍៖ ប្តូរ ord_st ទៅជា "ស្ថានភាពការបញ្ជាទិញ៖ 1=រង់ចាំការបង់ប្រាក់ 2=បានដឹកជញ្ជូន"។ នៅពេលដែលសហការីអាចយល់ពី field ទាំងនោះ ទើបពួកគេអាចស្វែងរកទិន្នន័យដោយខ្លួនឯងបាន។ រឿងនេះហាក់បីដូចជាធុញទ្រាន់បន្តិច ប៉ុន្តែវាជាកត្តាកំណត់ថាតើប្រព័ន្ធនឹងត្រូវប្រើប្រាស់ដែរឬទេ។

រឿងដែលត្រូវយកចិត្តទុកដាក់៖ តម្លៃគឺជាអន្ទាក់ធំបំផុត

កំណែ Open-source ដែលសាងសង់ដោយខ្លួនឯងគឺឥតគិតថ្លៃ។ កញ្ចប់សេវាកម្ម Cloud បង់ប្រាក់គឺគិតថ្លៃ តាមចំនួនមនុស្ស (Per-seat pricing)

  • Starter៖ ១០០ ដុល្លារក្នុងមួយខែ (បង់ប្រ instalments ប្រចាំឆ្នាំ ៩០ ដុល្លារ) រួមបញ្ចូលមនុស្ស ៥ នាក់ លើសពីនេះគិតប្រាក់ ៦ ដុល្លារក្នុងមនុស្សម្នាក់ក្នុងមួយខែ
  • Pro៖ ៥៧៥ ដុល្លារក្នុងមួយខែ (បង់ប្រចាំឆ្នាំ ៥១៧.៥ ដុល្លារ) រួមបញ្ចូលមនុស្ស ១០ នាក់ លើសពីនេះគិតប្រាក់ ១២ ដុល្លារក្នុងមនុស្សម្នាក់ក្នុងមួយខែ
  • Enterprise៖ តម្លៃតាមការស្នើសុំ ចាប់ផ្តើមពី ២ ម៉ឺនដុល្លារក្នុងមួយឆ្នាំ

អន្ទាក់ដ៏ធំបំផុតគឺ៖ អ្នកប្រើប្រាស់ដែលត្រូវបាន embed ឱ្យអតិថិជនខាងក្រៅមើលក៏ត្រូវបានរាប់បញ្ចូលជាមនុស្សម្នាក់ដែរ។ ប្រសិនបើអ្នកមានគម្រោង embed Dashboard ទៅក្នុងផលិតផល SaaS ឱ្យអតិថិជនមើល តម្លៃនៃគំរូនេះនឹងមានទំហំធំខ្លាំងណាស់ សូមធ្វើការគណនាមុនជាមុនសិន។ ក្រុមជាច្រើនបានរកឃើញរឿងនេះលុះត្រាតែពួកគេទទួលបានវិក្កយបត្រដំបូង។

បន្ថែមពីលើនេះ កំណែសាងសង់ដោយខ្លួនឯង មិនមានមុខងារ SSO និងការគ្រប់គ្រងសិទ្ធិយ៉ាងលម្អិតលើជួរដេក/ជួរឈរ (Row/Column permissions) នោះទេ។ ប្រសិនបើទិន្នន័យរបស់អ្នកមានផ្ទុកព័ត៌មានផ្ទាល់ខ្លួន ប្រាក់ខែ ឬទិន្នន័យរសើបឆ្លងផ្នែក អ្នកត្រូវគិតគូរឱ្យបានច្បាស់លាស់អំពីផ្នែកសិទ្ធិអំណាចនេះ ដែលប្រហែលជាត្រូវពឹងផ្អែកលើ view នៅកម្រិត Database ដើម្បីទប់ស្កាត់។

ចំណុចមួយទៀត៖ ឥតគិតថ្លៃមិនមែនមានន័យថាគ្មានថ្លៃដើមនោះទេ។ ការសាងសង់ដោយខ្លួនឯងត្រូវមានអ្នកមើលការខុសត្រូវលើ Database ការអាប់ដេត និងការสำรองទិន្នន័យ ដែលទាំងនេះសុទ្ធតែជាថ្លៃដើមផ្នែកធនធានមនុស្សដែលលាក់កំបាំង។

ស្ថានភាពដែលមិនគួរប្រើប្រាស់វា

ការវិភាគស្មុគស្មាញនៅតែតម្រូវឱ្យមានការសរសេរ SQL។ ចំណុចប្រទាក់បែបចុច (Click-based) មិនអាចដោះស្រាយតម្រូវការដូចជា CTE ច្រើនស្រទាប់ ឬ Window Functions បានទេ។ ប្រសិនបើការវិភាគរបស់អ្នកទាមទារការគំរូស្ថិតិ (Statistical modeling) ឬម៉ាស៊ីនរៀន (Machine learning) អ្នកគួរតែប្រើប្រាស់ Python ដោយមិនត្រូវបង្ខំឧបករណ៍ BI ឱ្យធ្វើនោះឡើយ។

ប្រសិនបើអ្នកចង់តភ្ជាប់លំហការងារទិន្នន័យ (Data workflow) ប្រកបដោយប្រព័ន្ធ អ្នកអាចយោងទៅលើ ការចងក្រងឧបករណ៍វិភាគទិន្នន័យ AI នៅលើគេហទំព័រ ឬមើលពាក្យបញ្ជាវិភាគទិន្នន័យនៅក្នុង បណ្តុំគំរូ Prompt

មតិយោបល់ពី TheAI學院

ខ្ញុំបានឃើញក្រុមហ៊ុនជាច្រើនទិញឧបករណ៍ BI ថ្លៃៗ ប៉ុន្តែចុងក្រោយមានតែក្រុមទិន្នន័យទេដែលប្រើប្រាស់វា ចំណែកឯផ្នែកអាជីវកម្មនៅតែត្រឡប់ទៅសួរវិស្វករដដែល។ មូលហេតុដែល Metabase អាចសម្រេចជោគជ័យបាន មិនមែនមកពីមុខងារច្រើនជាងគេនោះទេ ប៉ុន្តែគឺដោយសារតែ វាធ្វើឱ្យបុគ្គលិកដែលមិនមែនជាអ្នកបច្ចេកទេសហ៊ានចុចប្រើប្រាស់វាដោយខ្លួនឯងពិតប្រាកដ

មតិយោបល់៖តម្លៃរបស់ Metabase មិនស្ថិតនៅលើភាពស្អាតនៃរបាយការណ៍នោះទេ ប៉ុន្តែវាស្ថិតនៅលើការដោះបន្ទុក "ការទាញយកទិន្នន័យ" ចេញពីស្មារបស់វិស្វករ។ ប៉ុន្តែកុំឱ្យពាក្យថា "Open-source ឥតគិតថ្លៃ" បោកបញ្ឆោតឱ្យសោះ ការគិតថ្លៃតាមមនុស្ស និងកម្លាំងពលកម្មថែទាំ គឺជាថ្លៃដើមពិតប្រាកដ។

យោបល់ជាក់ស្តែងសម្រាប់អ្នកអាន៖ ដំបូងឡើយសូមប្រើប្រាស់ Docker ដើម្បីសាងសង់កំណែ Open-source ដោយខ្លួនឯង ចំណាយពេលមួយសប្តាហ៍ដើម្បីបង្កើត "តួលេខទាំងដប់ដែលក្រុមហ៊ុនសួរញឹកញាប់បំផុត" ទៅជា Dashboard មួយ និងកំណត់ការផ្ញើជូនអ្នកគ្រប់គ្រងដោយស្វ័យប្រវត្តិរៀងរាល់សប្តាហ៍។ អត្រាទទួលបានផលចំណេញ (ROI) នៃការធ្វើបែបនេះគឺខ្ពស់បំផុតក្នុងចំណោមដំណើរការដំឡើងទាំងមូល។ រហូតដល់ពេលដែលអ្នកពិតជាត្រូវការ SSO ឬត្រូវ embed ឱ្យអតិថិជនមើល សឹមធ្វើការវាយតម្លៃលើកញ្ចប់បង់ប្រាក់ — ហើយពេលវាយតម្លៃ សូមប្រាកដថាបានគណនាថ្លៃសេវាសម្រាប់អ្នកប្រើប្រាស់ខាងក្រៅបញ្ចូលគ្នាផង។

ប្រភពទិន្នន័យ

រៀបចំឡើងយោងតាមព័ត៌មានជាសាធារណៈ ដោយយកព័ត៌មានផ្លូវការជាគោល។ តម្លៃជាក់ស្តែងអាចមានការកែសម្រួល។

សំណួរញឹកញាប់

តើកំណែប្រភពបើកចំហ (Open Source) របស់ Metabase ឥតគិតថ្លៃទាំងស្រុងមែនទេ?

ការអាជ្ញាប័ណ្ណកម្មវិធីគឺឥតគិតថ្លៃ ដោយមិនកំណត់ចំនួនអ្នកប្រើប្រាស់ និងមុខងារនោះទេ។ ប៉ុន្តែត្រូវយកចិត្តទុកដាក់លើចំណុចពីរ៖ ទីមួយ ការដំឡើងដោយខ្លួនឯងទាមទារកម្លាំងពលកម្មក្នុងការថែទាំ (មូលដ្ឋានទិន្នន័យ ការអាប់ដេត ការបម្រុងទុក) ដែលនេះជាចំណាយលាក់កំបាំង។ ទីពីរ កំណែប្រភពបើកចំហមិនមានមុខងារ SSO និងការគ្រប់គ្រងសិទ្ធិជួរ/កော်ដាច់ខាតនោះទេ ដូច្នេះអង្គភាពដែលមានទិន្នន័យរសើបប្រហែលជាត្រូវពឹងផ្អែកលើការទប់ស្កាត់តាមរយៈ view នៃមូលដ្ឋានទិន្នន័យផ្ទាល់។

តើអាចទុកចិត្តលើ SQL ដែលបង្កើតដោយ AI ទាំងស្រុងបានទេ?

ការស្វែងរកសង្ខេបសាមញ្ញៗមានកម្រិតភាពត្រឹមត្រូវល្អ ប៉ុន្តែនៅពេលដែលពាក់ព័ន្ធនឹងការ join តารางច្រើន ឬតក្កវិជ្ជាអាជីវកម្មជាក់លាក់របស់ក្រុមហ៊ុន វាងាយនឹងមានកំហុសណាស់។ វាត្រូវបានណែនាំឱ្យចាត់ទុកវាជាឧបករណ៍សម្រាប់បង្កើតសេចក្តីព្រាង ដោយត្រូវពិនិត្យមើល SQL ដោយខ្លួនឯងជាមុនសិនមុនពេលដំណើរការ។ ការយកទិន្នន័យដែលផលិតដោយ AI ទៅធ្វើការសម្រេចចិត្តផ្ទាល់ គឺមានហានិភ័យខ្ពស់ណាស់។

តើត្រូវយកចិត្តទុកដាក់លើអ្វីខ្លះ នៅពេលฝັງ (Embed) ផ្ទាំងគ្រប់គ្រងឱ្យអតិថិជនមើល?

រឿងសំខាន់បំផុតគឺការគិតថ្លៃ។ ផែនការបង់ប្រាក់របស់ Metabase គិតថ្លៃតាមចំនួនអ្នកប្រើប្រាស់ ហើយអតិថិជនខាងក្រៅដែលមើលផ្ទាំងគ្រប់គ្រងបន្ទាប់ពីฝັງចូលក្នុងផលិតផល ក៏ត្រូវបានរាប់បញ្ចូលជាអ្នកប្រើប្រាស់ដែរ។ ប្រសិនបើផលិតផលរបស់អ្នកមានអតិថិជនរាប់រយនាក់ ថ្លៃដើមនឹងមានទំហំធំធេងណាស់ ដូច្នេះមុនពេលអនុវត្តត្រូវតែគណនាជាមុនសិន កុំចាំដល់ពេលទទួលបានវិក្កយបត្រទើបដឹង។

បើប្រៀបធៀបជាមួយ Looker Studio តើគួរជ្រើសរើសមួយណា?

ប្រសិនបើទិន្នន័យរបស់អ្នកស្ថិតនៅក្នុងប្រព័ន្ធអេកូឡូស៊ី Google (GA4, BigQuery, Sheets) ហើយតម្រូវការមានភាពសាមញ្ញ Looker Studio គឺឥតគិតថ្លៃ និងគ្រប់គ្រាន់ហើយ។ ប្រសិនបើទិន្នន័យស្ថិតនៅក្នុង MySQL/PostgreSQL ផ្ទាល់ខ្លួន ត្រូវការការគ្រប់គ្រងសិទ្ធិលម្អិត ឬចង់ដំឡើងដោយខ្លួនឯងដើម្បីរក្សាទុកទិន្នន័យនៅខាងក្នុង Metabase គឺសាកសមជាងយ៉ាងខ្លាំង។

繁體中文版 →