產品設計中的延遲資料

語言: CN / TW / HK

編輯導語:在付費軟體中,有時因遺忘續費、請款流程等原因,一些使用者沒有辦法在到期到日當天就完成續費,所以存在著時間差,在這個週期內未續費的使用者不一定是真的流失,這裡的“續費率”就是一個延遲資料。本文作者以產品A為例,分析產品中的延遲資料,一起來看一下吧。

產品 A 是一款付費軟體,小明是產品 A 的運營同學,近日正在針對產品 A 的續費情況做資料分析,希望來判斷產品 A 近期的續費狀況。小明調研後獲得了4-18~4-22的續費資料,並對比了去年同一日期的續費率,獲得了以下的折線圖:

2022和2021年續費資料對比

觀察圖表中的資料,可以發現,藍色折線代表了2022年4月18-22日的續費率,呈快速上升的表現,短短5天從20%到110%,甚至出現了超過100%的反常資料,正常認知下續費率是不會大於100%的

同時對比去年同一時間的續費率,續費率是穩定在50%左右的,因此我們可以得出4月份的這部分調研續費率資料是存在誤差的,對此小明作出了進一步的調研。

為此小明專門調查了4月18日-22日到期使用者的續費時間,分析後得到如下表格:

4/18-4/22續費情況

研究這個表格我們可以看出,隨著日期往後推移,在某一天續費的使用者其到期時間分佈的是在不同的日期的,例如以4月22日為例,4月18日到期了100 個使用者,但其續費的使用者並不是僅在4月18日續費。

從表格中我們可以發現,4月18日到期的使用者數除了在18日續費了20個,19、21 和22日均有續費,其中4月18日到期4月18日續費是屬於按時續費,存在 20 個使用者。

而4月19 ,21和22日續費,其續費時間已經大於4月18日這個到期時間了,這些日期續費就屬於一個延遲續費,這3日的資料分別如下:

  • 4 月 18 日到期,19 日續費的使用者數是 10 個
  • 4 月 18 日到期,21 日續費的使用者數是 10 個
  • 4 月 18 日到期,22 日續費的使用者數是 5 個

則延遲續費的使用者總數為 25 個。這裡可以發現,4月18日到期的使用者,其續費時間並不是僅僅在4月18日,在19日、21日和22日均有分佈。

而小明在統計續費率時只統計了18日到期18日續費的使用者,從而使得續費率大大減少,僅20%,彙總續費使用者後得出的續費率(20+10+10+5)/100 = 45%,接近歷史續費率 50%,是一個較為符合續費現象的資料。

帶著這個“到期使用者並一定在到期當天進行續費”的疑問,小明找這部分使用者調研和走訪,發現因遺忘續費、請款流程等原因,一些使用者沒有辦法在到期到日當天就完成續費。

這裡就存在一個時間差,這裡18-22號之間的4天就是一個時間差,在這個週期內未續費的使用者不一定是真的流失,只有當4天之後沒有續費,才是一個流失使用者,這裡的“續費率”就是一個延遲資料,續費週期為4天。本文就想和大家討論產品中的延遲資料。

01 什麼是延遲資料

先給“延遲資料”1 個定義:延遲資料是指推遲產出的資料,像文章開頭的續費率中,4月18日的續費率在4月18日產出,是一個理論上的資料產出時間。

我們認為4月18日到期的使用者是否會續費在4月18日當天就能確定,但是由於現實情況中“不是所有使用者都能夠在到期當天”完成續費。

導致了4月18日到期的使用者在後4天都有續費產生,因此4月18日的續費率是一個“4月18日到期,4月18日之後4天”續費的一個數據。

這就存在了一個推遲產生的過程,而這個推遲產出的資料,也就是我們所說的延遲資料。

在定義中我們看到延遲資料出現的原因是因為業務場景導致的,顧名思義就是產品設計時,從業務方面的因素考慮,當真實的業務是一個延遲場景時,為了讓資料更真實地還原業務場景,將欄位設計成延遲欄位。

例如在續費率的案例中,因為續費這個場景是個延遲場景,使用者因為請款、遺忘等原因,導致了本應該在到期當天的續費動作,發生在了到期日之後的日期中。

如果我們不將“續費率”設定成一個延遲資料,在不延遲的情況下18日到期的續費率就是18日到期然後18日續費的客戶,而真實的業務中,18日到期的客戶會在18-21日都產生續費動作。因此“續費率”需要設計成一個T+4 天后更新的延遲欄位。

02 什麼場景下需要延遲資料

從什麼是延遲資料中,我們已經瞭解到業務場景會導致我們將欄位設計成延遲欄位,那麼具體什麼樣的業務場景會需要這樣設定呢?

當業務場景中定製的規則,存在跨自然天規則時,也就是存在超過1天及以上的時間跨度時,就會需要設計成“延遲欄位”。

如果我們不將其設計成“延遲欄位”,就會導致統計出結果的時間跨度是小於業務場景中的時間跨度,從而使得最終的資料結果小於真實的業務資料。

以此資料做出的判斷和動作都將是錯誤的,從而產生運營上的失誤,甚至嚴重的帶來直接的經濟損失。而我們將其設計成“延遲欄位”的話,就可以充分準確地反應了真實的業務資訊,從而為我們後續的決策和動作提供資料基礎。

接下來我們一起來看下這部分業務場景具體有哪些,其中包括業務規則本身要求 和根據業務主動調整兩種情況。

1. 業務規則本身要求

這裡的業務規則本身,指的是“時間跨度”是由業務自身的規則所導致的,一起看下下面兩種交易規則:

  1. 使用者在證券平臺A掛單希望買入股票1,根據證券平臺的交易規則,訂單隻在交易時間段有效,即9:00-12:00和13:00-15:00,超過時間未成交的訂單,將作廢
  2. 使用者在電商平臺B下單希望買入商品1,根據該電商平臺的交易規則,訂單在下單後24小時內有效,超時未完成付款,則該訂單關閉

證券平臺A中的規則,規則本身提供的交易時間段都在自然天內,所以掛單當日的訂單是否成交,在掛單當天都可以產出,訂單有效時間沒有跨天,不存在延遲產出的情況。

而在電商平臺中,使用者在N日瀏覽,在N日建立了訂單,而根據平臺的訂單的支付有效期規則:24小時內有效,超時未完成付款,訂單關閉。

我們可以得出N日建立的訂單,實際的支付時間可以是在N日或N+1日。所以如果我們要了解電商平臺N日建立的訂單的支付成功情況,會有以下幾種情況:

  • N 日建立的訂單 N 日支付成功,N 日可確認這部分資料
  • N 日建立的訂單 N+1 日支付成功,N+1 日可確認這部分資料
  • N 日建立的訂單 N 日訂單關閉(平臺關閉或使用者手動關閉),N 日可確認這部分資料
  • N 日建立的訂單 N+1 日後因超時 24 小時訂單關閉,N+1 日才可以確認這部分資料

綜上可見,我們想要得出N日建立的訂單,最終的訂單狀態,需要等待N+1 日才可以得到,並以此來計算一下對運營動作具有參考價值的欄位。這裡就是一個因業務規則本身要求導致跨天性的資料延遲。

2. 根據業務主動調整

“根據業務主動調整”,通常是指業務並不是一個固定的業務,會因為一些時間、使用角色等外在因素導致變化。

不同的外在因素使得同一個業務的規則會變化。外在因素改變後,如果我們不去相容變化後的規則,會導致該業務產出的資料失真,失去意義,無法表現真實的業務情況。

當業務規則的時間跨度從當天,變成了跨自然天,這裡為了適應業務規則的變化,就要求我們改變成延遲欄位。

一起來看一下根據業務主動調整的案例,某電商平臺對內部客服有考核客服是否有回覆消費者。

通常情況下,消費者和客服的諮詢都發生在自然天內,所以只需要統計消費者諮詢後,客服當天是否有進行回覆,若沒有回覆,則計入回覆未達標數量為1。

當該電商平臺進入直播/大促等活動時,受限制於活動時間通常在0點開始,這就導致了活動開始前,即11點-0點期間湧入大量的消費者諮詢,而客服受到回覆能力限制,沒有辦法一一進行及時回覆,產生了大量在0點後的回覆。

這個情況下,要考核客服是否有回覆消費者,如果只看只看消費者諮詢當天是不太合理的,會產生大量因為客服爆線導致的回覆未達標資料,而這部分資料並不是客服主觀上沒有回覆消費者,所以需要這裡需要調整為看消費者當天 T和 T+1 天客服是否有回覆,這樣統計出來的回覆達標情況,是相對準確的。

結合“業務規則本身要求”和“根據業務主動調整”兩個一起來看,兩者的共同點都是因為“業務中存在跨自然天”的場景,從而需要延遲產出資料,差異在於“業務規則本身”是其業務規則不變的,而“根據業務主動調整”則是業務規則會隨著時間等外在因素變化。

03 設計延遲資料方案需要考慮的點

在瞭解完什麼是延遲資料和什麼場景下會出現延遲資料後,我們就需要設計資料延遲方案了,那麼在設計過程中,我們需要考慮哪一些要點呢?

1. 明確延遲週期

無論是上文2中業務場景中的哪一種導致的延遲資料,當存在延遲資料的情況時,就需要明確延遲週期,T日的業務,結果需要在T+N日產出,結合不同的業務情況,定義好延遲的天數,這就確定了資料延遲方案中最重要的一步。

像文章開頭中,續費業務中大部分的延遲續費在4天內,因此定義了延遲週期4天,因此資料是在T+4日內出來的。

在延遲週期內,資料更新的方式又存在兩種,一種是每日更新,另一種是在資料產出當天統一進行計算。

前一種計算方式可以針對實時檢視延遲資料的情況,例如T+4的續費率一般在60%,在T+1看到一個續費率是30%,可以瞭解兩者之間的差異,以便於展開一些運營活動。

另一種就保證了不會因為變化的資料產生一些干擾性和歧義,且計算更加簡單,只需要計算一次。

2. 延遲概念的透出和展示

確定延遲後,需要考慮使用者能否理解延遲這個問題,所以需要在頁面上做出相關的說明。不然會存在使用者諮詢資料為何沒有產出的疑問和諮詢。

第一種,可以通過系統的公告的方式來告知使用者資料延遲了,這種方式通常針對因臨時性原因導致的短暫延遲,所以可以用臨時性的公共方案來解決這個問題。

例如在電商產品在雙11等大促期間,因資料量劇增,導致資料晚於原定時間出現,這裡就可以上一個公告以進行說明,幫助使用者瞭解資料延遲的原因,避免因資料延遲帶來損失。

相較於第一種常用於解決臨時性延遲的方案,另一種,針對長期的延遲,例如產品設計方案設計的需要延遲的場景,我們可以將其作為一個常態化的功能,當資料在延遲日期內,或者包含了延遲期間的資料,我們可以在欄位旁邊對其做出特殊說明,讓使用者理解這部分欄位是存在延遲的。

04 總結

本文,我們一起了解了,延遲資料其實是一種資料更新頻率,當本應出現數據的日期沒有出現數據,那麼就可以認為是一個延遲資料了,其通常出現於因業務因素導致的資料無法更新場景,包括“業務規則本身要求”和“根據業務規則主動調整”這兩種情況。

#專欄作家#

晌午,微信公眾號:晌午自習室,人人都是產品經理專欄作家。5年產品經驗,專注於資料方向,目前是電商客服領域的產品 。

本文原創釋出於人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基於CC0協議