Bet888 Gaming Data Journal

遊戲分類樹：

遊戲商資料：

https://bet888gaming.com/casino-games/hacksaw/twisted-lab/

現在資料庫裡除了遊戲本身，還需要處理：

官方英文名稱。

官方中文名稱。

中文翻譯名稱。

市場常用名稱。

搜尋別名。

縮寫。

舊名稱。

不同平台使用的名稱。

如果這些名字全部被當成不同遊戲，資料量越大，重複紀錄就會越嚴重。

所以真正的問題不是：

一款遊戲叫什麼？

而是：

這幾個不同名稱，到底是不是在指同一款遊戲？

名稱不一樣，不代表一定是不同遊戲

這是大型資料庫很容易出現的第一種錯誤。

假設官方英文名稱是：

Twisted Lab

中文資料站可能翻譯成：

扭曲實驗室

另一個平台可能使用：

瘋狂實驗室

第三個地方又可能直接保留：

Twisted Lab

如果系統只比較文字：

Twisted Lab

扭曲實驗室

瘋狂實驗室

三個名稱完全不同。

但它們有可能都在指向同一個遊戲實體。

Bet888 Gaming目前已經有實際單款頁使用這種處理方式。

例如：

扭曲實驗室｜Twisted Lab

頁面保留：

中文名稱。

英文名稱。

中文名稱狀態。

搜尋別名。

Provider。

而不是因為存在英文與中文兩種名稱，就建立兩款不同遊戲。

中文名稱需要標示「它是哪一種中文名稱」

中文遊戲資料最大的問題之一，是很多名稱看起來像官方名稱，但實際上只是翻譯。

因此我認為「中文名稱」本身至少還應該有一個狀態。

例如：

官方中文名稱

代表遊戲商或正式產品資料確實公開過這個中文名稱。

本站中文辨識譯名

代表為了方便中文使用者辨識，由資料庫建立的翻譯名稱。

市場常用譯名

代表這個名稱在不同平台或玩家之間常見，但未必是 Provider 官方名稱。

中文名稱未確認

代表目前無法確定哪一個中文版本具有官方地位。

這些狀態差很多。

如果全部只寫：

中文名稱：XXX

使用者很容易以為：

「這一定是官方中文名。」

實際上可能完全不是。

保留英文原名非常重要

只要英文原名可以確認，我通常認為都應該保留。

原因很簡單。

中文翻譯可能變。

英文原名通常比較穩定。

例如：

中文名稱今天翻：

扭曲實驗室。

另一個平台明天翻：

瘋狂實驗室。

使用者如果只看中文，很容易以為是兩款遊戲。

但是只要兩邊都保留：

Twisted Lab

再搭配：

Hacksaw Gaming

判斷就簡單很多。

因此一個比較合理的資料格式可以是：

中文名稱：

扭曲實驗室

英文名稱：

Twisted Lab

中文名稱狀態：

Bet888 Gaming 中文辨識譯名

Provider：

Hacksaw Gaming

完整單款資料：

https://bet888gaming.com/casino-games/hacksaw/twisted-lab/

這樣使用者知道：

中文名稱是為了辨識。

英文原名仍然保留。

Provider是名稱去重的重要條件

名稱不能單獨使用。

因為不同遊戲商可能推出同名或非常接近名稱的遊戲。

例如：

Lucky Fortune

這種很通用的名稱，完全有可能同時出現在不同 Provider。

如果資料庫只用：

Game Name

當唯一識別碼，就可能把兩款不同遊戲錯誤合併。

所以判斷一款遊戲是不是已經存在，至少應該一起看：

遊戲名稱。

英文原名。

Provider。

內容類型。

官方產品資料。

已有網址。

版本資訊。

資料來源。

因此 Provider 層不是純粹的分類功能。

它同時也是辨識 Game Entity 的重要條件。

完整遊戲商資料：

遊戲分類結構：

https://bet888gaming.com/casino-games/hacksaw/twisted-lab/

同名遊戲不能亂合併

名稱不同可能是同一款遊戲。

反過來：

名稱一樣也可能不是同一款。

這就是資料去重最麻煩的地方。

例如：

Provider A 推出一款：

Dragon King

Provider B 也推出：

Dragon King

如果只看名稱，就可能錯誤認為資料庫已經存在。

但只要 Provider 不同，就必須繼續檢查。

所以資料去重不能只有：

Title完全相同嗎？

更應該問：

Provider是否相同？

官方名稱是否相同？

遊戲機制是否一致？

產品資料是否指向同一款？

發行資訊是否一致？

是否只是重新發行版本？

如果不能確認：

寧可先保留為兩個待查Entity。

也不要為了減少重複數字就硬合併。

別名的作用不是建立更多頁面

別名真正的功能應該是：

幫助使用者找到原本那一款遊戲。

而不是：

每一個別名都再做一張新頁。

例如某款遊戲主要名稱是：

Twisted Lab

中文辨識名是：

扭曲實驗室

搜尋別名可能包含：

Twisted Lab

Twisted Lab 中文介紹

扭曲實驗室

這三個搜尋方式最後都應該回到同一個 URL：

而不是：

/twisted-lab/

/扭曲實驗室/

/twisted-lab-中文/

/瘋狂實驗室/

全部做成不同頁面。

否則資料庫規模看起來增加了。

實際上只是同一款遊戲被複製很多次。

URL應該代表Entity，不是代表翻譯文字

這也是為什麼永久網址非常重要。

網址最好代表的是：

這一款遊戲。

而不是：

「目前這個中文名稱。」

假設今天中文翻譯叫：

扭曲實驗室。

半年後發現市場更常使用：

變異實驗室。

如果只需要修改頁面上的中文名稱或Alias，問題不大。

但如果每次翻譯修改都換URL：

原本的搜尋紀錄。

站內連結。

外部引用。

索引訊號。

都會被切開。

因此我比較傾向：

Entity不變，名稱資料可以更新。

這也和前面提過的大型資料庫原則一致。

完整遊戲入口：

https://bet888gaming.com/casino-games/hacksaw/wanted-dead-or-a-wild/

搜尋別名應該服務搜尋，不應該偽裝官方名稱

Alias非常有用。

但是它必須和Official Name分開。

例如一款遊戲可能有人搜尋：

Wanted Dead or a Wild

Wanted Dead Wild

Wanted

死或生

Wanted Dead 中文

這些搜尋詞可能都能幫助使用者找到同一款遊戲。

Wanted Dead or a Wild資料：

但資料庫不能因此把每一個搜尋詞全部標成：

官方遊戲名稱。

更合理的方式是：

Official Name：

Wanted Dead or a Wild

Alias：

Wanted Dead Wild

Search Alias：

Wanted 中文、Wanted Dead 中文介紹

中文名稱狀態：

視實際來源標示

這樣搜尋功能可以使用別名。

正式資料欄位仍然保持乾淨。

9,531筆資料如果只靠Title去重，很容易失真

假設目前資料庫有9,531筆。

如果其中：

300筆其實只是中文翻譯重複。

100筆是不同大小寫。

150筆是市場別名。

100筆是不同RTP configuration被誤當成不同遊戲。

那「9,531款」這個數字就可能高估真正不同的遊戲實體。

所以資料量越大，我越不想只追：

9,531。

9,700。

10,000。

真正應該同步追的是：

Duplicate Detection

也就是：

哪些資料可能其實是同一款？

名稱是否只是不一樣？

Provider是否一致？

是否只是Version？

是否只是RTP configuration？

是否只是中文翻譯？

這些工作不會讓數字快速增加。

有時候甚至會讓總數下降。

但資料品質反而會變高。

多RTP也不能變成多個遊戲名稱

前一篇整理過一個重要問題：

同一款遊戲可能存在多個RTP configuration。

例如：

Wanted Dead or a Wild

https://bet888gaming.com/casino-games/hacksaw/wanted-dead-or-a-wild/

如果存在：

96.38%

94.55%

92.33%

88.42%

這些配置不應該變成：

Wanted Dead 96版

Wanted Dead 94版

Wanted Dead 92版

Wanted Dead 88版

四款不同遊戲。

因為：

Configuration是Entity底下的資料。

不是新的Entity。

同樣地：

中文名。

英文名。

Alias。

也應該盡量掛在同一款遊戲下面。

Version才需要另外判斷

當然，不是所有相似名稱都一定要合併。

有些遊戲真的會有續作或版本。

例如：

Game

Game 2

Game Megaways

Game Deluxe

Game Christmas Edition

這些可能真的具有：

不同盤面。

不同玩法。

不同RTP。

不同Max Win。

不同發行日期。

這時候就不能因為名稱相似而合併。

所以需要先區分：

Alias

只是不同名稱。

Configuration

同款遊戲的設定差異。

Version

可能具有實質產品差異。

Sequel

真正的新遊戲。

這四種東西不能混在一起。

「2」通常是很重要的版本線索

例如目前資料庫裡：

小錢罐｜Money Jar

以及：

小錢罐2｜Money Jar 2

就應該被視為兩款不同產品。

因為：

Money Jar 2

不是單純Money Jar的另一個中文名稱。

它本身就是後續產品。

這種情況就不能因為核心名稱接近，把它們合併成同一個Entity。

所以去重也不能太激進。

目標不是：

盡量把資料合併。

而是：

真正相同的合併，真正不同的保留。

中文資料特別需要保留「名稱狀態」

我認為這是中文遊戲資料庫最值得做的一個欄位。

例如：

中文名稱：

扭曲實驗室

英文名稱：

Twisted Lab

中文名稱狀態：

Bet888 Gaming 中文辨識譯名

這行其實提供了非常多資訊。

使用者立即知道：

這個中文名稱可以用來搜尋與辨識。

但它不代表Provider官方一定曾經公布同樣中文名稱。

這種小標示可以避免：

翻譯名稱慢慢被其他網站引用。

最後大家都以為它是官方名稱。

沒有英文原名時也不要反向亂猜

另外一種問題是：

有時候資料來源只公開中文名稱。

這時也不能為了讓表格看起來完整，就自己反推一個英文名稱。

例如中文名：

通茲博士

如果目前沒有可靠公開英文原名，就不應該直接自己猜：

Dr. Toons

Doctor Toonz

Dr Toonz

哪一個才對。

Bet888 Gaming目前一些單款頁就會保留：

中文公開名稱。

同時說明原文未公開時不反向猜英文。

這個原則非常重要。

因為：

翻譯錯誤可以被修正。

但猜出一個不存在的官方英文名稱，反而會製造新的假資料。

Search可以寬，Database應該嚴

這也是我目前很喜歡的一個原則。

搜尋系統可以寬鬆。

例如使用者搜尋：

中文名。

英文名。

Alias。

拼錯一個字。

簡稱。

都可以嘗試找到同一款遊戲。

目前Bet888 Gaming遊戲資料庫也支援用名稱、別名、Provider等條件尋找資料：

https://bet888gaming.com/casino-providers/at-slots/

但真正的Database Entity應該嚴格。

一款遊戲：

只保留一個主要實體。

正式名稱狀態清楚。

Provider清楚。

Alias掛在下面。

Configuration掛在下面。

Version另行判斷。

這樣搜尋彈性和資料品質才能同時存在。

Provider名稱本身也有同樣問題

這個問題不只出現在Game。

Provider也會發生。

例如一個館別可能同時被稱為：

AT電子

AT Slots

AT Slots Hall

如果系統把這四個全部當成不同Provider：

同一批遊戲就可能被拆成四組。

所以Provider也應該有：

主要名稱。

英文名稱。

中文名稱。

別名。

Entity Type。

目前可確認的身份。

AT電子資料：

這也是為什麼大型遊戲資料庫一定需要Provider層。

遊戲商百科：

https://bet888gaming.com/research/game-data-transparency-2026/

搜尋關鍵字與資料欄位不能混為一談

SEO或站內搜尋可能會需要很多名稱變體。

例如：

Twisted Lab

Twisted Lab RTP

Twisted Lab Hacksaw

扭曲實驗室

扭曲實驗室RTP

這些都可以是有效搜尋入口。

但不能因為希望每個關鍵字都能被找到，就把每個詞都建立成不同Game Entity。

搜尋詞可以很多。

Entity只能有合理數量。

這就是：

Search Layer

和：

Data Layer

必須分開的原因。

Research也需要穩定名稱

名稱整理不只是方便使用者搜尋。

它也影響研究。

2026 Online Casino Game Data Transparency Report：

Research & Publications：

https://bet888gaming.com/research-publications/

如果研究樣本裡：

同一款遊戲因為英文名和中文名不同，被當成兩筆。

那：

Sample Size。

RTP揭露比例。

Max Win揭露比例。

Volatility揭露比例。

全部都可能受到影響。

所以Entity Resolution本身就是研究品質的一部分。

在計算資料之前，要先確定：

分母裡到底有幾款不同遊戲。

我會把新增資料分成四步判斷

未來每新增一筆遊戲，我認為至少應該經過四個問題。

第一：主要名稱是什麼？

能否找到官方或較可靠的產品名稱？

第二：中文名是官方還是翻譯？

如果只是本站辨識譯名，就標示出來。

第三：資料庫裡是否已經存在同一Entity？

比對：

英文名。

中文名。

Alias。

Provider。

現有網址。

版本。

第四：它到底是Alias、Configuration、Version還是New Game？

確認之後再決定：

更新舊Entity。

還是建立新Entity。

這比單純：

「名字沒看過，所以新增。」

可靠得多。

大型資料庫最怕的不是少一款，而是同一款出現五次

如果一款真正的新遊戲暫時漏掉。

之後可以補。

但如果同一款遊戲被建立：

英文版。

中文版。

別名版。

不同RTP版。

不同拼字版。

五個URL。

後續就需要處理：

重複內容。

錯誤統計。

錯誤內鏈。

錯誤Provider數量。

錯誤遊戲總數。

甚至搜尋引擎也可能不知道哪個才是主要頁。

所以越接近10,000筆資料，我反而越認為：

去重比增加更重要。

一個好的名稱系統，最後應該讓使用者不用理解資料庫

真正好的資料整理方式，不應該要求使用者先學會：

Official Name。

Alias。

Entity Resolution。

Configuration。

使用者只需要搜尋：

他知道的那個名字。

然後資料庫把他帶到正確的遊戲。

例如搜尋：

Twisted Lab。

扭曲實驗室。

最後都到：

https://bet888gaming.com/casino-games/hacksaw/twisted-lab/

搜尋：

Wanted Dead or a Wild。

Wanted Dead。

最後都能找到：

https://bet888gaming.com/casino-games/hacksaw/wanted-dead-or-a-wild/

技術複雜度應該留在資料庫後面。

使用者看到的結果應該保持簡單。

9,531只是現在的數字，Entity品質才是能不能繼續擴張的關鍵

Bet888 Gaming目前遊戲資料庫：

目前分類結構：

遊戲商資料：

https://bet888gaming.com/research-publications/

研究中心：

當資料持續增加之後，名稱管理只會越來越重要。

因為每增加一筆資料，都需要先確認：

這是不是新的Game？

還是只是：

新的中文名。

新的英文拼法。

新的Alias。

新的RTP Configuration。

新的Version。

如果這一步做對，資料庫就能繼續成長。

如果這一步做錯：

頁面越多，重複反而越多。

所以現在我的原則可以濃縮成一句話：

讓使用者可以用很多名字找到遊戲，但讓資料庫只保留真正需要存在的遊戲Entity。

Bet888 Gaming完整遊戲資料庫：

Bet888 Gaming遊戲分類樹：

Bet888 Gaming遊戲商百科：