ReferOn將安全性視為聯盟行銷平台核心 強調單一入口與充足容量

ReferOn首席產品官Vlad Bondarenko指出，聯盟軟體處於一個尷尬的位置，營運商透過它提交報告，聯盟夥伴則將其數據視為收入基礎，但雙方都無法打開黑箱檢查內部運作。

他表示，「剩下的就是信任，但這是一個很薄弱的營運基礎。」他認為，安全性在歷史上往往是在平台架構建立後才被處理，這可能隨著業務增長而產生難以解決的漏洞。

Bondarenko解釋，「在大多數平台上，安全性來得很晚。這並非出於疏忽，我也從未見過有人在規劃會議上反對它，只是它從來不是當前最緊急的問題。」

ReferOn在重建基礎設施時採取了不同方法，將安全性視為平台的根本部分，而非額外的保護層。該平台透過集中入口點處理所有流量，並使用Cloudflare作為反向代理。

其基礎設施在亞馬遜雲端運算服務（AWS）上運行，並由Kubernetes管理地理分散的節點。網頁應用程式防火牆保護、速率限制和分散式阻斷服務（DDoS）緩解均透過Cloudflare實施。

Bondarenko強調，價值不在於個別安全工具，而在於確保每個請求都遵循相同的受控路徑。「重要的是只有一扇門。一個監視流量的地方，一個應用規則的地方，一個任何查看者都能看到變更的地方。」

該平台透過程式碼定義基礎設施，使變更能夠被記錄、審查並一致地複製，以消除未記錄的修復導致平台預期與實際運作產生差異的風險。

Bondarenko認為，抗壓能力應獲得與防止未經授權存取同等的關注。「容量通常被歸類為性能而非安全問題，我認為這是錯誤的。一個沒有剩餘餘裕的系統會以無人預料的方式故障。」

ReferOn報告其重新導向服務在六個實例上每秒處理超過4000個請求，同時保持CPU使用率低於50%。該平台在服務層級記錄的第95百分位重新導向延遲為4.8毫秒，第99百分位延遲為5毫秒。

「我們遠未接近任何極限，因此大型活動啟動帶來的流量高峰只是平常的一天，而非事故。」Bondarenko表示。

在數據隔離方面，ReferOn採用租戶架構，每筆記錄都分配給特定的客戶環境，為每個營運商的聯盟夥伴、追蹤連結和報告資訊建立邏輯邊界。

Bondarenko解釋，「請求要麼在租戶邊界內解決，要麼完全無法解決。」對於需要額外隔離的營運商，ReferOn也提供專用資料庫或Kubernetes叢集。

其追蹤系統使用內部生成的追蹤和點擊識別碼，使佣金計算和報告能在無需識別個別玩家的情況下運作。「佣金邏輯、獎勵計算和報告都基於這兩者。在這條鏈中的任何地方都不需要解析點擊背後的玩家是誰。」

在開發者存取方面，ReferOn的工程師在本地工作，無法存取生產叢集，減少了敏感憑證透過開發活動暴露的風險。變更透過自動化管道引入，功能在隔離環境中測試後逐步發布。

Bondarenko指出，在一個聯盟夥伴或多或少認為數據會在事後被悄悄調整的市場中，能夠向他們展示一份實體上無法更改的記錄，其價值遠高於僅僅告訴他們沒有被調整。

該平台在至少三個獨立的AWS可用區域運行每個應用程式的實例，以減少對單一實體位置的依賴。交易數據透過具有自動故障轉移和時間點恢復功能的Amazon RDS維護。