從一次深夜直播搶購開始,一條數(shù)據(jù)跨越服務(wù)器、風(fēng)控系統(tǒng)與推薦算法的奇幻漂流。揭秘電商平臺如何通過埋點(diǎn)采集、分布式架構(gòu)與實(shí)時計(jì)算,將0.3秒的點(diǎn)擊轉(zhuǎn)化為精準(zhǔn)營銷決策,構(gòu)建比用戶更了解自己的數(shù)字畫像。
———— / BEGIN / ————
周四晚上10點(diǎn)17分。
小林縮在被窩里,手機(jī)屏幕的藍(lán)光打在她臉上。直播間里,主播舉著一件米白色羽絨服,背景音樂的節(jié)奏越來越快,越來越緊。屏幕右下角的倒計(jì)時從”59秒”跳到”38秒”,彈幕像瀑布一樣往上涌——”沖!””家人們搶到了!””最后一波!”
小林的大腦還沒反應(yīng)過來,手指已經(jīng)按下去了。
“立即購買。”
從她手指離開屏幕,到頁面彈出”下單成功”,中間只有不到0.3秒。
但就在這0.3秒里,有一個東西誕生了。
它叫做——一條數(shù)據(jù)。
而我,就是它。
我將要開啟一段旅行:跨越數(shù)十臺服務(wù)器,穿越數(shù)千公里光纖,被數(shù)十個系統(tǒng)反復(fù)讀寫、拆解、重組、分析。沒有人告訴小林這一切的存在,但這一切,從她手指落下的那一刻起,就已經(jīng)開始了。
第一站:誕生——我的”出生證明”
小林以為她只是”買了件衣服”。
但我的出生證明上,密密麻麻寫滿了她不知道的信息。
在App還沒上線的時候,產(chǎn)品經(jīng)理和工程師就已經(jīng)在每一個用戶可能觸發(fā)的關(guān)鍵動作上,悄悄”埋下”了感應(yīng)器。點(diǎn)擊按鈕、滑動頁面、停留超過3秒、把商品加進(jìn)購物車……
每一個動作,都對應(yīng)一個預(yù)設(shè)的感應(yīng)器。一旦被觸發(fā),感應(yīng)器就會自動把現(xiàn)場所有信息打包,生成一條數(shù)據(jù)——也就是我。
這套機(jī)制,在行業(yè)里叫做埋點(diǎn)系統(tǒng)。
我的出生證明上寫著:
是誰:小林的用戶ID(一串加密編號,她本人也不知道自己的編號是什么)、她手機(jī)的設(shè)備ID(相當(dāng)于這臺手機(jī)的”身份證號”)。
在哪:直播間的唯一ID、主播的ID、當(dāng)前頁面的路徑——精確到”她是從推薦流滑進(jìn)這個直播間的,還是搜索進(jìn)來的,還是點(diǎn)了主播的專屬鏈接”。
買什么:商品ID、SKU編號(不只是”羽絨服”,而是”米白色、L碼”這個具體規(guī)格)、價格、數(shù)量。
當(dāng)時狀態(tài):WiFi連接、iPhone 15、App版本7.23.1。
精確時間:22:17:43.271——不是”10點(diǎn)多”,是精確到毫秒的時間戳。
還有兩個細(xì)節(jié),是大多數(shù)人想不到的。
第一個:我記錄了小林點(diǎn)擊屏幕的坐標(biāo)位置——X軸第347像素,Y軸第891像素。為什么?因?yàn)槿绻c(diǎn)擊位置偏離按鈕中心太遠(yuǎn),說明可能是誤觸。誤觸率高的訂單,退款率也更高。產(chǎn)品經(jīng)理會用這個數(shù)據(jù)來決定”購買按鈕”應(yīng)該做多大、放在屏幕哪個位置。
第二個:我記錄了小林在這件羽絨服的商品卡片上停留了47秒。這個數(shù)字說明她糾結(jié)過——她認(rèn)真看了,不是沖動點(diǎn)的。相比那些停留2秒就下單的用戶,她的退貨可能性更低。平臺會用這個數(shù)據(jù)來預(yù)測”哪些訂單更容易被退貨”。
把我想象成一個剛出生的嬰兒。醫(yī)院不只是給他起個名字,還要測身高、體重、血型,記錄出生時間、順產(chǎn)還是剖腹產(chǎn)、媽媽的病歷號、接生醫(yī)生的工號……我的誕生,也是如此事無巨細(xì)。
第二站:起跑——數(shù)據(jù)包的”快遞分揀”
我出生的那一刻,就開始了奔跑。
但我的目的地不是”平臺總部的某臺服務(wù)器”——我的旅程,更像一次快遞運(yùn)輸。
![]()
我離開小林的手機(jī),第一站不是北京,而是上海本地的一個CDN節(jié)點(diǎn)。
CDN,全名”內(nèi)容分發(fā)網(wǎng)絡(luò)”,可以理解成遍布全國的快遞網(wǎng)點(diǎn)。如果每一條數(shù)據(jù)都要從用戶手機(jī)直接跑到平臺總部,那上海的用戶要跑到北京,廣州的用戶也要跑到北京,光是路上的時間就會把那0.3秒全部耗光。
CDN的存在,就是讓數(shù)據(jù)先”就近入庫”,再走高速干線——就像你在上海寄順豐快遞去北京,快遞員不會從你家直接開車去北京,而是先送到附近的網(wǎng)點(diǎn),走航空干線,再到北京分揀中心派送。
從邊緣節(jié)點(diǎn)出發(fā),我沿著高速光纖骨干網(wǎng)抵達(dá)平臺的核心數(shù)據(jù)中心,然后來到第一道真正的門——API網(wǎng)關(guān)。
這是所有外部請求的統(tǒng)一入口。
門衛(wèi)會檢查:你的請求格式合法嗎?你攜帶了正確的”通行證”(Token)嗎?你有沒有在瘋狂刷接口?通過了,才能進(jìn)去。
但此刻,不只我一個人在跑。同一秒鐘,可能有50萬人都點(diǎn)下了”立即購買”。如果這50萬個請求全部涌向同一臺服務(wù)器,服務(wù)器會在0.01秒內(nèi)崩潰。所以API網(wǎng)關(guān)后面,還有一個負(fù)載均衡器——它像春運(yùn)時火車站開了20個安檢通道,把50萬個請求均勻分配給背后成百上千臺服務(wù)器,每臺只處理一小部分,大家一起扛。
這就是為什么雙十一的時候,你的App沒有崩——不是因?yàn)榉?wù)器夠強(qiáng),而是因?yàn)榉?wù)器夠多、分工夠好。
第三站:驗(yàn)關(guān)——風(fēng)控系統(tǒng)的”三重審查”
進(jìn)了數(shù)據(jù)中心,我以為旅行會順利很多。
沒想到,這里才是最嚴(yán)格的關(guān)卡。
![]()
第一重:身份驗(yàn)證。
系統(tǒng)收到我之后,第一件事不是處理我,而是問:這真的是小林本人發(fā)出來的嗎?
驗(yàn)證方式是檢查我身上攜帶的Token——一串加密字符串,相當(dāng)于小林登錄時服務(wù)器頒發(fā)給她的”臨時通行證”。Token有有效期,通常是幾小時到幾天。如果過期了,或者被人篡改過,我會被直接拒絕,系統(tǒng)要求小林重新登錄。
第二重:設(shè)備指紋識別。
光有Token還不夠。系統(tǒng)還會核對設(shè)備指紋——這是通過手機(jī)的屏幕分辨率、系統(tǒng)版本、字體列表、GPU型號等幾十個參數(shù),合成的一個唯一標(biāo)識。即使黑產(chǎn)換了賬號,只要用的還是同一臺設(shè)備,風(fēng)控系統(tǒng)就能認(rèn)出來。
第三重:實(shí)時風(fēng)控模型。
這是最復(fù)雜的一關(guān),也是戲劇性最強(qiáng)的一關(guān)。
風(fēng)控引擎要在50毫秒以內(nèi),對我這筆交易打一個綜合風(fēng)險分。它考量的維度包括:這個賬號注冊多久了?歷史購買記錄正常嗎?這次下單的速度是否異常快——正常人從進(jìn)直播間到下單,至少需要幾秒,而機(jī)器人可能0.1秒就完成;這個商品是不是正在被大量異常賬號集中購買(黃牛掃貨的特征);這個IP地址有沒有出現(xiàn)過欺詐行為;小林的賬號和已知欺詐賬號有沒有關(guān)聯(lián)關(guān)系……
風(fēng)險分低于閾值,放行。風(fēng)險分高,攔截。介于中間的,觸發(fā)”柔性攔截”——彈出滑塊驗(yàn)證或短信驗(yàn)證。這就是為什么有時候你換了新手機(jī)、換了城市登錄,下單會突然彈出”請完成驗(yàn)證”。系統(tǒng)不是在刁難你,它只是對這次操作的置信度不夠高,在用戶體驗(yàn)和安全之間,選了一個折中的方案。
把這三關(guān)想象成機(jī)場安檢:查身份證、過人臉識別、安檢儀掃行李。大多數(shù)普通旅客三關(guān)秒過。但如果你的行李里有什么異常,就會被拉到旁邊”開箱檢查”。
而那些試圖用機(jī)器人批量下單的黃牛,就像拿著假證件混入機(jī)場的人。風(fēng)控系統(tǒng)每天都在和它們玩貓鼠游戲。
第四站:分裂——一個請求觸發(fā)的”多米諾骨牌”
通過了三重驗(yàn)關(guān),我終于被放行。
然后,我”爆炸”了。
不是真的爆炸——而是一個請求,瞬間觸發(fā)了八個不同系統(tǒng)同時開始工作。
早期的電商系統(tǒng)是”一體式”的,所有功能——訂單、庫存、支付、物流——都寫在一個大程序里。這樣的問題是:一個功能出了bug,整個系統(tǒng)都崩。后來工程師們把這個大程序拆成了很多小程序,每個只負(fù)責(zé)一件事,互相獨(dú)立,通過接口通信。這就是微服務(wù)架構(gòu)。
小林那一次點(diǎn)擊,觸發(fā)了什么?
![]()
訂單服務(wù)生成了一個全平臺唯一的訂單號,寫入數(shù)據(jù)庫,狀態(tài)標(biāo)記為”待支付”。庫存服務(wù)對這件米白色L碼羽絨服執(zhí)行了”庫存鎖定”——注意,不是直接扣減,而是先”預(yù)占”。為什么?因?yàn)槿绻×窒聠魏蟛桓犊睿瑤齑婢桶装妆绘i住了,別人也買不了。支付服務(wù)調(diào)起了收銀臺,等待小林完成支付。優(yōu)惠計(jì)算服務(wù)飛速檢查小林賬戶里有沒有可用優(yōu)惠券、是否滿足滿減、是否有會員折扣,實(shí)時算出最終應(yīng)付金額。
與此同時,訂單服務(wù)把”有一筆新訂單”這條消息扔進(jìn)了消息隊(duì)列(Kafka)。消息通知服務(wù)、直播數(shù)據(jù)服務(wù)、推薦服務(wù)——它們不需要等訂單服務(wù)直接通知,而是自己去隊(duì)列里取消息,各自處理,互不干擾。
這就是消息隊(duì)列的價值:解耦。就像大型餐廳后廚的”出菜口”——服務(wù)員不需要站在每個廚師旁邊等,只需要把單子夾在出菜口,廚師們自己來取。就算某個廚師臨時去廁所了(某個服務(wù)臨時掛了),單子還在出菜口等著,他回來繼續(xù)做,不會丟。
但這里有一個極其棘手的問題,工程師們稱之為分布式事務(wù)難題:庫存服務(wù)和支付服務(wù)是兩個獨(dú)立的系統(tǒng),運(yùn)行在不同的服務(wù)器上。如果庫存鎖定成功了,但支付失敗了,庫存要不要”還回去”?如何保證多個獨(dú)立系統(tǒng)的操作要么全部成功,要么全部回滾?這是電商工程里最復(fù)雜的問題之一,也是每一次大促前,工程師們最擔(dān)心的事情。
第五站:落庫——數(shù)據(jù)的”三居室”
支付成功。
我正式成為了一條”已完成交易數(shù)據(jù)”,需要找一個地方住下來。
但我不能只住一個地方——因?yàn)椴煌A段,我被”需要”的方式完全不同。
![]()
剛剛產(chǎn)生的訂單,接下來幾小時會被高頻讀寫:小林刷新頁面查訂單狀態(tài),支付結(jié)果回調(diào)來更新狀態(tài),客服查詢訂單詳情……這些操作要求極低延遲,所以我先住進(jìn)Redis——一種把數(shù)據(jù)直接存在內(nèi)存(RAM)里的數(shù)據(jù)庫,讀寫速度比普通硬盤快100倍以上。這就是”床頭柜”:隨手就能拿到,但只能放幾件東西,而且貴。
等支付完成、訂單進(jìn)入物流履約階段,訪問頻率下降,我就搬進(jìn)了MySQL——存在硬盤上,有完善的索引和查詢優(yōu)化,能住幾個月。這是”衣柜”:稍微走幾步,但容量大得多。
幾個月后,訂單完結(jié),我被歸檔進(jìn)數(shù)據(jù)倉庫(Hive/ClickHouse)。在這里,我不再被單獨(dú)查詢,而是和億萬條數(shù)據(jù)一起,等待被批量分析——”上個季度羽絨服品類的退貨率是多少?””米白色比深藍(lán)色賣得更好嗎?”這類問題,就是在這里找答案的。這是”儲物間”:要專門去找,但能存放海量東西,而且便宜。
這套分層存儲的設(shè)計(jì),背后是一個樸素的工程權(quán)衡:熱數(shù)據(jù)用貴的快速存儲,冷數(shù)據(jù)用便宜的慢速存儲。整體成本大幅降低,用戶體驗(yàn)(查訂單狀態(tài)不用等)也得到了保證。這不只是技術(shù)決策,更是產(chǎn)品經(jīng)理和架構(gòu)師共同算出來的一筆經(jīng)濟(jì)賬。
第六站:流動——實(shí)時數(shù)據(jù)的”神經(jīng)系統(tǒng)”
與此同時,在我被安置進(jìn)各個”居室”的同時,另一個系統(tǒng)也在悄悄盯著我——實(shí)時數(shù)據(jù)流。
直播間后臺的運(yùn)營團(tuán)隊(duì),此刻正盯著一塊大屏幕。屏幕上的數(shù)字每隔幾秒就在跳動:GMV、下單人數(shù)、轉(zhuǎn)化率、各SKU的庫存余量……
這些數(shù)字是怎么做到實(shí)時刷新的?
傳統(tǒng)的數(shù)據(jù)分析是批處理:等數(shù)據(jù)積累一整天,晚上統(tǒng)一計(jì)算,第二天早上出報(bào)告。就像你每個月月底才對一次賬。這在直播場景里完全行不通——主播說錯一句話,轉(zhuǎn)化率可能在30秒內(nèi)暴跌,等你第二天早上發(fā)現(xiàn),黃花菜都涼了。
所以直播電商依賴的是流式計(jì)算(Apache Flink):來一條數(shù)據(jù),處理一條數(shù)據(jù),結(jié)果實(shí)時產(chǎn)出。我這條訂單數(shù)據(jù)一進(jìn)入Kafka消息隊(duì)列,F(xiàn)link就立刻消費(fèi)它,把它納入實(shí)時聚合計(jì)算,結(jié)果寫入Redis,前端大屏每秒輪詢Redis拿最新數(shù)據(jù),渲染到屏幕上。整個鏈路的端到端延遲,通常在3秒以內(nèi)。
這套實(shí)時數(shù)據(jù)系統(tǒng)能做什么?運(yùn)營團(tuán)隊(duì)可以秒級監(jiān)控GMV,判斷當(dāng)前節(jié)奏是否達(dá)標(biāo);某款商品上架后,前5分鐘轉(zhuǎn)化率如果低于預(yù)期,立刻換貨;實(shí)時分析彈幕里的關(guān)鍵詞情緒,如果”太貴了””不好看”開始大量出現(xiàn),系統(tǒng)會提醒運(yùn)營介入;某個SKU庫存低于安全線,實(shí)時觸發(fā)補(bǔ)貨提醒。
流式計(jì)算就像醫(yī)院的心電監(jiān)護(hù)儀——它不是每天早上給你出一份”昨日心跳報(bào)告”,而是實(shí)時顯示每一次心跳的波形。直播間的實(shí)時數(shù)據(jù)大屏,就是這場商業(yè)演出的”心電圖”。批處理則像體檢——一年做一次,數(shù)據(jù)很全面,但你不可能靠體檢來判斷”我現(xiàn)在心臟有沒有問題”。
第七站:沉淀——”數(shù)字小林”的誕生
幾天過去了。
小林的羽絨服到貨了,她確認(rèn)收貨,訂單關(guān)閉。
我以為旅行結(jié)束了。
但事實(shí)上,我正在經(jīng)歷最深刻的一次變化——我即將成為構(gòu)成”數(shù)字小林”的一塊拼圖。
數(shù)據(jù)從業(yè)務(wù)數(shù)據(jù)庫進(jìn)入數(shù)據(jù)倉庫,需要經(jīng)過一個叫ETL的流程:先從MySQL、Redis、日志系統(tǒng)等多個數(shù)據(jù)源抽取(Extract)原始數(shù)據(jù);再轉(zhuǎn)換(Transform)——清洗掉臟數(shù)據(jù)、統(tǒng)一字段格式、做必要的計(jì)算和關(guān)聯(lián);最后加載(Load)進(jìn)數(shù)據(jù)倉庫。就像你把家里各個房間的東西全部搬出來,按類別重新整理,放進(jìn)統(tǒng)一的收納柜。
數(shù)據(jù)倉庫里,每個用戶都有一張畫像檔案。這張檔案由成百上千個標(biāo)簽構(gòu)成:
![]()
我這筆訂單,給小林的畫像帶來了三個具體變化:新增了”羽絨服購買者”、”直播場景轉(zhuǎn)化用戶”、”夜間高活躍”三個標(biāo)簽;更新了她近30天的客單價區(qū)間,從”200\~400元”升級為”300\~600元”;強(qiáng)化了”限時促銷敏感型”這個標(biāo)簽——因?yàn)樗窃诘褂?jì)時38秒時下單的,說明她對”快要沒了”這種緊迫感有強(qiáng)烈反應(yīng)。
用戶畫像就像一份越來越厚的個人檔案。每一次行為,都在這份檔案上添加新的記錄。時間越長,這份檔案越厚,平臺對你的了解也越深——甚至可能比你自己更了解你想要什么。
第八站:覺醒——算法開始”投喂”
第二天上午10點(diǎn)整,小林的手機(jī)震動了一下。
一條推送通知:”羽絨品類專屬福利,限時3天,為你定制。”
她以為這是隨機(jī)發(fā)的廣告。
其實(shí),這條通知的每一個細(xì)節(jié),都是算法精心計(jì)算過的。
平臺識別出小林剛購買了羽絨服,正處于”品類興趣峰值期”——這是購買同品類關(guān)聯(lián)商品概率最高的時間窗口。根據(jù)她的客單價區(qū)間,系統(tǒng)設(shè)計(jì)了對她有吸引力的券面額。有效期被設(shè)定為3天,而不是30天——30天太長,會被遺忘;3天制造緊迫感,但又不會讓人覺得太有壓力。推送時間選在上午10點(diǎn),因?yàn)檫@是她的歷史活躍時段。
這背后是推薦系統(tǒng)在工作。推薦系統(tǒng)的核心問題只有一個:在海量商品里,找到最可能讓某個特定用戶產(chǎn)生購買行為的那幾件商品。
它有兩條主要路徑:協(xié)同過濾,”和你行為相似的人,還買了這些”——找到與小林購買行為相似的用戶群體,把他們買過但小林沒買的東西推給她;內(nèi)容推薦,”你買了羽絨服,所以推薦配套的圍巾”——基于商品屬性關(guān)聯(lián)做推薦。現(xiàn)代推薦系統(tǒng)通常是兩者結(jié)合,再加上深度學(xué)習(xí)模型做排序,給每個候選商品打一個”推薦分”,分?jǐn)?shù)最高的展示在最前面。
但平臺不會把同一套推薦策略用在所有人身上。他們會同時運(yùn)行多個版本——A版本給小林推圍巾,B版本給小林推羽絨褲——隨機(jī)分配給不同用戶,對比哪個版本的點(diǎn)擊率和轉(zhuǎn)化率更高,然后把更好的版本推廣給所有人。這就是A/B測試,互聯(lián)網(wǎng)產(chǎn)品迭代的基本方法論。
互聯(lián)網(wǎng)公司每天都在對你做成千上萬個這樣的”小實(shí)驗(yàn)”,只是你不知道而已。你以為你在自由瀏覽,其實(shí)你是實(shí)驗(yàn)組里的一個樣本。
推薦算法就像一個極其了解你的朋友,他不只知道你買了什么,還知道和你”同類型”的人都在買什么,然后把兩個信息結(jié)合起來給你推薦——而且他從不休息,從不忘記,從不因?yàn)樾那椴缓枚o你亂推。
第九站:聚合——一滴水匯入大海
小林的故事,到這里似乎畫上了句號。
但我的旅行,還有最后一站。
小林的這筆訂單,對那家賣羽絨服的商家來說,是一條寶貴的信息。商家登錄平臺的數(shù)據(jù)后臺,可以看到:這款羽絨服在哪些人群中賣得最好(年齡、城市、性別分布);用戶從進(jìn)直播間到下單的平均時長,用來判斷主播的講解效率;哪個流量來源——自然流量、付費(fèi)推廣、主播分發(fā)——帶來的轉(zhuǎn)化率最高;退貨率最高的是哪個SKU,用來指導(dǎo)下一季的備貨決策。
這些數(shù)據(jù),會直接影響商家下一場直播的選品、定價、甚至選哪個主播來合作。
而當(dāng)數(shù)以億計(jì)的”小林們”的數(shù)據(jù)匯聚在一起,平臺能看到的,是整個消費(fèi)市場的脈搏:某個品類的需求正在崛起,平臺提前招募對應(yīng)類目的商家;某個地區(qū)的消費(fèi)力在提升,加大當(dāng)?shù)貍}儲投入;某種直播風(fēng)格的轉(zhuǎn)化率在下降,調(diào)整流量分發(fā)策略。這些洞察,會反過來影響平臺的產(chǎn)品策略、招商策略,甚至基礎(chǔ)設(shè)施的投資決策。
把每一條用戶數(shù)據(jù)想象成一滴雨水。單獨(dú)一滴,什么也做不了。但當(dāng)數(shù)十億滴雨水匯聚成河流,就能推動水輪機(jī)發(fā)電。這才是”大數(shù)據(jù)”的真實(shí)含義——不只是數(shù)據(jù)量大,而是聚合之后產(chǎn)生的洞察力。
這里有一個值得思考的問題,隨著我的旅行自然浮現(xiàn):這些數(shù)據(jù),到底屬于誰?屬于產(chǎn)生數(shù)據(jù)的小林?屬于收集數(shù)據(jù)的平臺?屬于使用數(shù)據(jù)的商家?
中國的《數(shù)據(jù)安全法》《個人信息保護(hù)法》正在逐步厘清這個邊界,但爭議還在持續(xù)。小林有權(quán)知道平臺用她的數(shù)據(jù)做了什么,有權(quán)要求刪除,有權(quán)拒絕被”畫像”——只是大多數(shù)人從來沒有想過去行使這個權(quán)利。
尾聲:0.3秒之后
現(xiàn)在,你知道了。
小林按下那個按鈕之后的0.3秒里,到底發(fā)生了什么。
一條數(shù)據(jù)在她手指離開屏幕的瞬間誕生,帶著密密麻麻的出生證明出發(fā);
它跑過上海的CDN節(jié)點(diǎn),沿著數(shù)千公里的光纖骨干網(wǎng)抵達(dá)數(shù)據(jù)中心;
它在50毫秒內(nèi)通過了三重風(fēng)控審查,被確認(rèn)是一個真實(shí)的人、一次真實(shí)的意圖;
它分裂成八個并行的任務(wù),在微服務(wù)的世界里引發(fā)了一場多米諾骨牌;
它按照”年齡”住進(jìn)了三種不同的存儲空間;
它變成了實(shí)時大屏上跳動的一個數(shù)字;
它參與構(gòu)建了”數(shù)字小林”的畫像;
它最終匯入了數(shù)十億條數(shù)據(jù)的海洋,成為驅(qū)動整臺商業(yè)機(jī)器運(yùn)轉(zhuǎn)的燃料之一。
而小林,已經(jīng)把手機(jī)放下,關(guān)燈睡著了。
她不知道這一切。
大多數(shù)人都不知道。
但這并不意味著這一切不重要。
恰恰相反——正因?yàn)檫@一切發(fā)生在看不見的地方,它才更值得被看見。
每一次你在直播間沖動下單,每一次你在搜索框里打下一個詞,每一次你在某個商品頁面多停留了幾秒,都在悄悄地、精確地、永久地,改變著平臺眼中的”你”是什么樣的人。
技術(shù)本身沒有善惡。讓數(shù)據(jù)旅行變得有意義的,是我們選擇如何理解它、如何使用它、以及如何在這個被數(shù)據(jù)深度滲透的世界里,依然保持清醒。
下次你再躺在被窩里刷直播,倒計(jì)時跳到38秒,彈幕里全是”沖!”
——也許你會想起這條數(shù)據(jù),想起它即將開始的旅行。
然后,你再決定要不要按下去。
本文來自公眾號:AI宇宙NPC小文作者:AI宇宙NPC小文
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布,本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.