使用者行為分析是企業瞭解使用者的重要方式之一，可以從點選、登入、觀看、跳出、下單購買等多維角度還原使用者動態使用場景和使用者體驗，透過對使用者行為埋點資料進行分析，可以詳細、清楚地瞭解使用者的行為習慣，從中發現使用者使用產品的規律，以用於精準營銷、產品最佳化，從而驅動業務實現增長。

隨著數字化轉型程式的不斷推進，使用者行為分析平臺在企業內部扮演的角色愈發重要，如何進一步挖掘使用者行為資料價值，也成為了當下各企業不斷努力探索的方向。而系統平臺建設過程中所遭遇的挑戰，也成了制約企業實現精細化運營過程中的重要因素。因此本文將從某社交 APP 的實際業務場景出發，與大家分享 [Apache Doris](<http:>) 如何助力企業構建高效的使用者行為分析平臺，實現資料驅動業務發展。

# **#  從一個業務場景說起**

在此以某社交 APP 為例，如果想要更好地提升使用者使用體驗並進一步實現轉化率的增長，基於使用者行為資料進行分析並調整業務相應策略是其中的關鍵，而各個業務團隊對使用者行為資料往往訴求存在一定差異：

-   演演算法團隊想知道該 APP 最近一段時間的使用者活躍資料，來判斷是否需要調整推薦演演算法；
-   商業部門想知道多少人觀看廣告後進行了點選，以分析廣告帶來的使用者體驗如何；
-   運營部門想知道多少人透過落地頁參與活動以及其轉化率，以判斷活動 ROI；
-   產品部門想知道不同功能使用者訪問資料的差異，透過 A/B 實驗指導正確的產品最佳化路徑；
-   ......

為了承接以上需求，過去該公司使用了基於 Hive 的離線資料倉儲，整體資料平臺架構如下：
![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c38be361c3ad4951963e4916be7e4012~tplv-k3u1fbpfcp-zoom-1.image)

-   原始資料主要來自關係型資料庫 MySQL 、訊息佇列 Kafka 以及採集到的日誌資料；
-   利用 Sqoop 和 DataX 進行資料同步，透過 Flink 和 Spark 進行 ETL 以及 Yarn 和 Airflow 進行作業和任務排程；
-   處理完成的資料落入 Hive ，Impala 作為分析引擎，為上層自研的 BI 產品提供互動式分析服務；

**在這樣的平臺架構下，留存著一系列挑戰有待解決：**

-   資料時效性較差：原有架構資料鏈路比較長，資料時效性差，T+1 的資料生產模式嚴重影響業務分析的效率；
-   運維成本高：資料鏈路較長，維護資料流轉的成本高，一旦出現問題則需要排查上下游多個系統；且 Impala 本身不具備儲存資料的能力，不得不引入 Hadoop 體系，而元件的繁多冗雜也大幅提升了企業運維的成本投入；
-   資料分析難度高：對於資料分析人員來說，沒有合適的分析函式將會帶來很多額外的工作量，比如編寫 SQL 邏輯冗長、執行 SQL 耗時耗力等，嚴重影響資料分析的效率。

以該公司資料為例，我們將 APP 資料簡化抽象出來，以一個常見需求來看資料分析的成本：

```sql
 -- APP使用者表
 CREATE TABLE app (
     id int,   -- 使用者id
     a_time datetime,   -- 動作的時間
     act varchar(20)  -- 動作（登入、觀看、點選等等）
 ) 
 unique key (id, a_time, act) 
 COMMENT 'OLAP' DISTRIBUTED BY HASH(`id`) BUCKETS 8  
```

```
```

以背景介紹中的需求為例，演演算法部門想知道該 APP 最近一段時間的使用者活躍及留存資料，來判斷是否需要進行推薦演演算法和展示頁的調整。上述其實就是一個求留存率的需求，實現邏輯並不複雜，我們可以很容易寫出如下SQL：

```sql
select dt, activ_2 / activ_1 as retention
from
(
    select to_date(aa.o_time) as dt, count(distinct a.id) as activ_1,
    count(distinct b.id) as  activ_2
    from app a
    left join app b
    on a.id = b.id and to_date(a.a_time) = days_add(to_date(b.a_time), 1)
    where to_date(a.a_time) = 'xxxx'
    group by to_date(aa.a_time)
) as aa
```

但其中不能忽視的問題出現了，我們每查詢一個留存比例就需要 Join APP 表自身一次，查詢多個比例則需要 Join 該表自身多次，SQL 語句變得無比冗長；同時當執行該 SQL 時，多表 Join 帶來的耗時也會變得很長。由此可知，**沒有合適的行為分析函式，會降低分析過程的效率。**

# **#  全新的使用者行為分析平臺**

經過慎重選型和對比，該公司決定使用 Apache Doris 來作為分析和計算引擎，主要考慮到如下優勢：

-   **資料整合簡易**：提供無縫接入 Kafka 和 MySQL 的能力，可複用已有架構並減少對接工作量；

-   **架構簡單**：只有 FE 和 BE 兩種角色，無需引入第三方元件，維護成本極低；

-   **效能優異**：列式儲存引擎、MPP 查詢框架、全向量化執行，在實際測試中效能表現突出；

-   **功能豐富**：支援豐富的使用者分析函式，分析結果即查即出；

-   ....

在引入 Apahce Doris 後，整體資料架構得到簡化，資料處理鏈路得到大幅縮短，以下是新的架構：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a848f3af10bf49c9a3ba232a9740b043~tplv-k3u1fbpfcp-zoom-1.image)

### **資料匯入更便捷**

首先，**Apache Doris 資料生態豐富，提供了多種資料匯入方式，與已有資料來源無縫對接：**

-   透過 Routine Load 可以直接訂閱 Kafka 資料；

-   透過 INSERT INTO SELECT

可以匯入外部表的資料，目前已支援 MySQL、Oracle、PostgreSQL、SQL Server 等多個資料來源；

-   透過 Stream Load 可以直接匯入本地資料檔案；

-   ......

使用者可以針對不同的資料來源選擇不同的資料匯入方式，以快速整合來自不同資料來源的資料。檔案參考：*https://doris.apache.org/zh-CN/docs/dev/data-operate/import/load-manual*

其次，**Apache Doris 1.2 版本中增加了 Multi-Catalog 功能**，可實現無縫對接外部異構資料來源，**使用者無需進行資料匯入**，即可直接透過建立 CREATE CATALOG  來查詢底層資料。相對外部表， Multi-Catalog 無需建立表與表之間的對映關係，可以實現後設資料層的對接，進一步加強聯邦資料分析能力。

```sql
-- 我們以mysql為例，來詳細講解讀取和寫入的具體實現

-- 建立catalog
CREATE CATALOG jdbc PROPERTIES (
    "type"="jdbc",
    "jdbc.user"="root",
    "jdbc.password"="123456",
    "jdbc.jdbc_url" = "jdbc:mysql://127.0.0.1:13396/demo",
    "jdbc.driver_url" = "file:/path/to/mysql-connector-java-5.1.47.jar",
    "jdbc.driver_class" = "com.mysql.jdbc.Driver"
);

其中jdbc.driver_url可以是遠端jar包：

CREATE CATALOG jdbc PROPERTIES (
    "type"="jdbc",
    "jdbc.user"="root",
    "jdbc.password"="123456",
    "jdbc.jdbc_url" = "jdbc:mysql://127.0.0.1:13396/demo",
    "jdbc.driver_url" = "https://path/jdbc_driver/mysql-connector-java-8.0.25.jar",
    "jdbc.driver_class" = "com.mysql.cj.jdbc.Driver"
);

-- 透過 SWITCH 命令切換到 jdbc catalog，並檢視其中的資料庫
MySQL [(none)]> switch jdbc;
Query OK, 0 rows affected (0.02 sec)

MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| __db1              |
| _db1               |
| db1                |
| demo               |
| information_schema |
| mysql              |
| mysql_db_test      |
| performance_schema |
| sys                |
+--------------------+

MySQL [demo]> use db1;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed

MySQL [db1]> show tables;
+---------------+
| Tables_in_db1 |
+---------------+
| tbl1          |
+---------------+

-- 使用catalog查詢外部資料來源
MySQL [db1]> select * from tbl1;
+------+
| k1   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
+------+

-- 建立doris表，注意schema與mysql一致
CREATE TABLE IF NOT EXISTS test.test (
    k1 int
)
DUPLICATE KEY(`col1`)
DISTRIBUTED BY HASH(col1) BUCKETS 1
properties(
"replication_num"="1"
);

-- 使用catalog直接將mysql中的資料匯入doris
-- 我們只用三級後設資料層級，catalog.db.table的方式
insert into internal.test.test select k1 from jdbc.db1.tbl1;
```

### **資料時效性提升**

資料架構簡潔有力，引入 Apache Doris 後，資料架構縮減到 3 層，有效避免了過長資料處理鏈路帶來的時延，整體資料時效性從**天級降至分鐘級**；

使用者查詢耗時更低，SQL 查詢耗時從過去的**分鐘降低至秒級甚至毫秒級**，極大提升了業務分析人員的分析效率。

### **資料分析效率進一步提升**

前文中有提到，沒有合適的分析函式會使得分析工作變得艱難；而 **Apache Doris 為使用者行為分析提供了豐富的分析函式，使得資料分析難度大幅降低**，這些函式包括但不限於：

-   intersect_count
-   sequence_count

-   sequence_match

-   retention
-   window_funnel
-   Array 類函式
-   ......

# **#  豐富的使用者行為分析函式**

### **資料準備**

在此以上述 APP 表為例，前期需要完成建表以及資料匯入等準備工作：

```sql
 -- 建表
 CREATE TABLE app (
     id int,   -- 使用者id
     a_time datetime,   -- 動作的時間
     act varchar(20)  -- 動作（登入、觀看、點選等等）
 ) 
 unique key (id, a_time, act) 
 COMMENT 'OLAP' DISTRIBUTED BY HASH(`id`) BUCKETS 8  
 PROPERTIES ("replication_allocation" = "tag.location.default: 1");
 
 
 -- 插入資料
insert into app values 
(111, '2022-01-01 10:00:00', 'login'), 
(111, '2022-01-01 10:01:00', 'view'),
(111, '2022-01-01 10:02:00', 'click'), 
(111, '2022-01-02 10:00:00', 'login'), 
(111, '2022-01-02 10:01:00', 'view'), 
(222, '2022-01-01 11:00:00', 'login'),
(222, '2022-01-01 11:01:00', 'view'), 
(333, '2022-01-01 12:00:00', 'login'),
(333, '2022-01-01 12:01:00', 'view'),
(444, '2022-01-01 13:00:00', 'login');
 
 -- 檢視資料
select * from app order by a_time;
+------+---------------------+-------+
| id   | a_time              | act   |
+------+---------------------+-------+
|  111 | 2022-01-01 10:00:00 | login |
|  111 | 2022-01-01 10:01:00 | view  |
|  111 | 2022-01-01 10:02:00 | click |
|  222 | 2022-01-01 11:00:00 | login |
|  222 | 2022-01-01 11:01:00 | view  |
|  333 | 2022-01-01 12:00:00 | login |
|  333 | 2022-01-01 12:01:00 | view  |
|  444 | 2022-01-01 13:00:00 | login |
|  111 | 2022-01-02 10:00:00 | login |
|  111 | 2022-01-02 10:01:00 | view  |
+------+---------------------+-------+
 
```

### **留存分析**

演演算法部門想知道該 APP 最近一段時間的使用者活躍及留存資料，來判斷是否需要進行推薦演演算法和展示頁的調整。該需求可以理解為留存率，主要是指註冊後在一定時間內或者一段時間後有登入行為且仍在繼續使用該產品的留存使用者，在當時總的新增使用者中所佔比例。該需求為前文提到的第一個需求，接下來我們看看使用 Doris 提供的分析函式如何實現呢？

**正交 Bitmap 函式計算留存率**

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2ed0f8b3b18542019ccd4db956c8135a~tplv-k3u1fbpfcp-zoom-1.image)

```sql
-- 求第N天登入的使用者
select intersect_count(to_bitmap(id), to_date(a_time), '2022-01-01') as first from app;
+-------+
| first |
+-------+
|     4 |
+-------+

-- 求第N天和N+1天都登入的使用者
select intersect_count(to_bitmap(id), to_date(a_time), '2022-01-01', '2022-01-02') as second from app;
+-------+
| second |
+-------+
|     1 |
+-------+

-- 二者的比例即為所求
select intersect_count(to_bitmap(id), to_date(a_time), '2022-01-01', '2022-01-02') / intersect_count(to_bitmap(id), to_date(a_time), '2022-01-01') as rate from app;
+------+
| rate |
+------+
| 0.25 |
+------+
```

**Retention 函式計算留存率**

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/da7fb878605943caac6cf6752cd728a5~tplv-k3u1fbpfcp-zoom-1.image)

Retention 通常需要跟`group by`聯合使用，以獲取`group by`列匹配的條件。而輸入的引數是可變長引數，Retention 會返回跟輸入引數長度相等的陣列。陣列取值則要看匹配條件能否滿足，如下圖所示：![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/527e972235754553b113a1555e2531be~tplv-k3u1fbpfcp-zoom-1.image)

```sql
-- 求第N天登入的使用者
select id, retention(to_date(a_time)='2022-01-01') as first from app group by id;
+------+-------+
| id   | first |
+------+-------+
|  222 | [1]   |
|  111 | [1]   |
|  444 | [1]   |
|  333 | [1]   |
+------+-------+

-- 求第N天和N+1天都登入的使用者
select id, retention(to_date(a_time)='2022-01-01', to_date(a_time)='2022-01-02') as second from app group by id;
+------+--------+
| id   | second |
+------+--------+
|  222 | [1, 0] |
|  111 | [1, 1] |
|  444 | [1, 0] |
|  333 | [1, 0] |
+------+--------+

-- 二者的比例即為所求
select sum(re[2])  / sum(re[1]) as rate  from (select id, retention(to_date(a_time)='2022-01-01', to_date(a_time)='2022-01-02') as re from app group by id) as a;
+------+
| rate |
+------+
| 0.25 |
+------+

```
### 路徑分析
商業部門想知道多少人觀看廣告後進行了點選，以分析廣告帶來的使用者體驗是否合適。該需求可以理解為行為分析中的路徑分析，而路徑分析是一種基於行為順序、行為偏好、關鍵節點、轉化效率的探索型模型。依據路徑分析可以直觀掌握使用者行為擴充套件路線，以供最佳化節點內容、提升整體轉化效率。

**sequence_count 路徑分析**

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3532bc3254804e7f97d8cb974a856dac~tplv-k3u1fbpfcp-zoom-1.image)

`sequence_count`通常需要跟`group by`一起使用，以獲取`group by`列匹配的條件。函式使用方法為：`sequence_count((?1)(?t<3600)(?2), date, col1=1, col3='a')`，表明當前 col1=1 是第一個條件；此時如果有 col2=a，並且 col2 的時間與 col1 的時間在 3600 秒之內(col2 的時間減去 col1 的時間)，則`sequence_count`對這樣一組匹配結果記一個數。其工作邏輯如下圖所示：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a12bdff3cecf4e0c9d70863bfe4836cc~tplv-k3u1fbpfcp-zoom-1.image)

```sql
 -- 哪些使用者在登入後2分鐘內觀看了廣告
select id, sequence_count('(?1)(?t<=120)(?2)', a_time, act = 'login', act = 'view') as result from app group by id;
+------+--------+
| id   | result |
+------+--------+
|  111 |      2 |
|  444 |      0 |
|  222 |      1 |
|  333 |      1 |
+------+--------+
-- 上述SQL可以看到，先觀看廣告再點選廣告的使用者有3人；而111這個使用者有兩次都是登入後觀看了廣告。pattern中的(?1)對應act = 'login'，(?2)對應act = 'view'，時間間隔為120秒

-- 哪些使用者在登入後2分鐘內觀看了廣告，並在2分鐘內點選了廣告
select id, sequence_count('(?1)(?t<=120)(?2)(?t<=120)(?3)', a_time, act = 'login', act = 'view', act = 'click') as result from app group by id;
+------+--------+
| id   | result |
+------+--------+
|  333 |      0 |
|  111 |      1 |
|  444 |      0 |
|  222 |      0 |
+------+--------+
```

### **漏斗分析**

運營部門想知道多少人透過落地頁參與活動以及其轉化率，以判斷活動 ROI 以及確定策略帶來的價值是否符合預期。該需求可以理解為轉化率，而轉化率主要是指是指使用者進行了相應目標行動的次數與總次數的比率；轉化率可以衡量一個產品使用者需求強弱、評價產品設計好壞、對比流程和渠道權重等。

**window_funnel 漏斗轉化分析**

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e2669658dac6495da197a6d13d95cc39~tplv-k3u1fbpfcp-zoom-1.image)
`window_funnel`也是有可變引數，並且需要指定時間視窗列和視窗大小。假設視窗大小為 3600 秒，並且`datetime`列為時間列，則視窗就是沿著`datetime`列滑動。首先匹配條件1 ，如果有一列滿足則待返回值變成1；然後去匹配條件 2，如果條件 2 匹配，並且跟條件 1 相差時間在 3600 秒內，則待返回值加一；接著匹配條件3，過程與條件2相同。最後返回一個計數值，該值表明這些可變條件滿足多少個。
![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4eec63b4eb8440a3bb986e3841de84f8~tplv-k3u1fbpfcp-zoom-1.image)

```sql
-- 哪些使用者在登入後2分鐘內觀看了廣告
select id, window_funnel(120, 'default', a_time, act = 'login', act = 'view') as w  from app  group by id;
+------+------+
| id   | w    |
+------+------+
|  333 |    2 |
|  222 |    2 |
|  111 |    2 |
|  444 |    1 |
+------+------+
-- 從上述SQL可以看出，第一個引數120秒指定了滑動視窗的大小，並且視窗是按a_time這一列滑動的。act = 'login', act = 'view'是兩個條件，顯然使用者111，222,333均滿足這兩個條件，即一小時內，先登入再觀看廣告；但是444這位使用者就不滿足先登入再觀看廣告，因為他只有登入操作，所以window_funnel對他返回了1，因為他只滿足第一個條件

-- 根據上述結果進行篩選，哪些使用者在登入後2分鐘內觀看了廣告
select id, window_funnel(120, 'default', a_time, act = 'login', act = 'view') as w  from app  group by id having w = 2;
+------+------+
| id   | w    |
+------+------+
|  111 |    2 |
|  333 |    2 |
|  222 |    2 |
+------+------+

-- 哪些使用者在一小時內，登入、觀看、點選都執行了
select id, window_funnel(3600, 'default', a_time, act = 'login', act = 'view', act = 'click') as w from app  group by id having w = 3;
+------+------+
| id   | w    |
+------+------+
|  111 |    3 |
+------+------+
```

### **其他**

#### **Array 類函式**

熟悉行為分析的同學都知道，固然豐富的分析函式有助於幫助我們提高分析效率，但是分析函式無法覆蓋所有的場景，一些特殊的需求還是依賴特殊或者複雜的 SQL 來實現，而這些 SQL 很多都需要藉助陣列來實現。鑑於篇幅所限，該部分不會展示紛繁複雜的需求，而是會透過幾個淺顯的例子來展示 Apache Doris 豐富的陣列類函式。

```sql
// split_by_string函式：指定分隔符切分字串，得到切分後的陣列：
select split_by_string('a#b#c#d','#');
+---------------------------------+
| split_by_string('a#b#c#d', '1') |
+---------------------------------+
| ['a', 'b', 'c', 'd']            |
+---------------------------------+

// array_sort函式：對陣列進行升序排序。下表的k1是陣列型別：
select k1, array_sort(k1) from test;
+-----------------------------+-----------------------------+
| k1                          | array_sort(`k1`)            |
+------+-----------------------------+----------------------+
| NULL                        | NULL                        |
| [1, 2, 3, 4, 5, 4, 3, 2, 1] | [1, 1, 2, 2, 3, 3, 4, 4, 5] |
+-----------------------------+-----------------------------+

// array_size函式：獲取陣列大小。下表的k1是陣列型別：
select k1,size(k1) from test;
+-----------+------------+
| k1        | size(`k1`) |
+-----------+------------+
| [1, 2, 3] |          3 |
| []        |          0 |
| NULL      |       NULL |
+-----------+------------+

// array_remove函式：返回移除所有的指定元素後的陣列。下表k1是陣列型別：
select k1, array_remove(k1, 1) from test;
+--------------------+-----------------------+
| k1                 | array_remove(k1, 1) |
+--------------------+-----------------------+
| [1, 2, 3]          | [2, 3]                |
| [1, 3]             | [3]                   |
| NULL               | NULL                  |
| [1, 3]             | [3]                   |
| [NULL, 1, NULL, 2] | [NULL, NULL, 2]       |
+--------------------+-----------------------+

// array_slice函式：返回一個子陣列，包含所有從指定位置開始的指定長度的元素。下表k1是陣列型別。從1開始從左至右計數；位置可以為負數，負數從-1開始從右到左開始計數

select k1, array_slice(k1, 2, 2) from array_type_table_nullable;
+-----------------+-------------------------+
| k1              | array_slice(`k1`, 2, 2) |
+-----------------+-------------------------+
| [1, 2, 3]       | [2, 3]                  |
| [1, NULL, 3]    | [NULL, 3]               |
| [2, 3]          | [3]                     |
| NULL            | NULL                    |
+-----------------+-------------------------+
select k1, array_slice(k1, -2, 1) from test;
+-----------+--------------------------+
| k1        | array_slice(`k1`, -2, 1) |
+-----------+--------------------------+
| [1, 2, 3] | [2]                      |
| [1, 2, 3] | [2]                      |
| [2, 3]    | [2]                      |
| [2, 3]    | [2]                      |
+-----------+--------------------------+

// array_distinct函式：去除陣列中的重複元素。下表k1是陣列型別
select k1, array_distinct(k1) from test;
+-----------------------------+---------------------------+
| k1                          | array_distinct(k1)        |
+-----------------------------+---------------------------+
| [1, 2, 3, 4, 5]             | [1, 2, 3, 4, 5]           |
| [6, 7, 8]                   | [6, 7, 8]                 |
| []                          | []                        |
| NULL                        | NULL                      |
| [1, 2, 3, 4, 5, 4, 3, 2, 1] | [1, 2, 3, 4, 5]           |
| [1, 2, 3, NULL]             | [1, 2, 3, NULL]           |
| [1, 2, 3, NULL, NULL]       | [1, 2, 3, NULL]     |
+-----------------------------+---------------------------+

// 配合array使用較多的explode函式，可以輕鬆實現列轉行：
select e1 from (select 1 k1) as t lateral view explode([1,2,3]) tmp1 as e1;
+------+
| e1   |
+------+
|    1 |
|    2 |
|    3 |
+------+

// explode_split函式：按分隔符分割字串，並將結果打散，實現列轉行：
select * from example1;
+---------+
| k1      |
+---------+
| a, b, c |
+---------+
select e1 from example1 lateral view explode_split(k1, ',') tmp1 as e1;
+------+
| e1   |
+------+
|  b   |
|  c   |
|  a   |
+------+
```

# **#  總結**

透過 Apache Doris 系統自身的優異能力和豐富的行為分析函式，已經有越來越多的企業選擇基於 Apache Doris 構建高效的使用者行為分析平臺，更多案例歡迎關注 SelectDB 公眾號以及相關技術部落格。後續我們仍會持續加強這方面的能力，包括提供更豐富的資料型別以及行為分析函式，如果您在搭建使用者行為分析平臺過程中遇到任何問題，歡迎聯絡社群進行支援。同時也歡迎加入 Apache Doris 社群，一起將 Apache Doris 建設地更加強大！

**作者介紹：**

李仕楊，SelectDB 生態研發工程師，Apache Doris Contributor</http:>

如何基於 Apache Doris 構建簡易高效的使用者行為分析平臺？

相關文章