How 360 Mobile Assistant Built a Scalable AI‑Powered App Recommendation System

Introduction

Recommendation technology, now a standard for internet products, addresses information overload and uncovers latent user needs. It began with Amazon's collaborative filtering, evolved through matrix factorization, and later focused on CTR prediction using models like LR, FM, GBDT, and their ensembles. Recent deep learning models such as Wide&Deep, DeepFM, and DIN have achieved strong results in CTR estimation.

In the 360 Mobile Assistant, app recommendations on the homepage, game page, and software page account for a large share of downloads. To increase user stickiness, the product also includes news and game videos, creating a challenge of mixing apps and content to boost download conversion and content clicks. This article outlines the business understanding, system architecture, core recommendation workflow, data warehouse construction, and online monitoring.

Business Scenarios

The low‑frequency app aims to satisfy both app‑search and post‑download user needs.

Business Characteristics

The app store presents several challenges:

Millions of apps, but only a few high‑quality ones, each with different lifecycles.

Low user activity and coarse‑grained user profiles.

Different popularity patterns for software and games, affecting download decisions.

Significant habit differences between new and old phones.

Multiple recommendation scenarios with varying optimization goals.

These factors lead to differing priorities across recommendation components.

To reduce maintenance overhead and hidden risks, the team modularizes and configures open‑source components wherever possible.

System Architecture

Overall framework:

Data Warehouse Layer

The algorithm team also handles data construction and analysis. A single‑layer architecture (interface → application) works for simple, low‑volume data sources but suffers from duplicated development, inconsistent definitions, and high maintenance cost. As data sources and business needs grew, a centralized, platform‑based data warehouse became necessary, providing:

Interface layer that abstracts diverse data sources.

Application layer ensuring data quality (completeness, timeliness, accuracy, uniqueness).

Layered design that reduces migration and maintenance costs, improves reuse, and offers a unified global view.

Computing Layer

The computing layer consists of offline and real‑time components, built on Spark, Hadoop MR, and HBox (which integrates TensorFlow, MXNet, Caffe, Theano, PyTorch, Keras, XGBoost, etc.).

Offline outputs include user portraits, trained models, indexes, personalized push lists, leaderboards, and reports.

Real‑time outputs include immediate user behavior feedback, short‑term item features, and server/business monitoring metrics.

Recommendation Engine Layer

The engine operates via configuration files that select recall data, ranking models, rule strategies, and operational interventions to produce a final recommendation list.

Example: App Recommendation

Data collection: User portrait and app feature data are logged in real time via Scribe, linked by a unique ID, cleaned, formatted as CSV, and stored in the data warehouse DM layer.

Metrics: CTR/CVR are used for app recommendation; for video/content recommendation, multi‑task learning (MTL) with an improved Wide&Deep model is explored.

Data sampling: Because exposure logs are massive but clicks are sparse, non‑exposed logs are filtered, and further up‑sampling/down‑sampling is applied based on optimization goals.

Features: Includes app basic attributes, statistical metrics, user demographics, device info, behavior attributes, contextual signals, and cross features.

Feature analysis helps improve model limits, detect hidden bugs, and assess quality via coverage, statistical moments, correlation, chi‑square, CTR, information gain, and AUC.

Recall methods include content‑based (using app name, description, tags), item‑based collaborative filtering, embedding‑based similarity (initial word2vec on install data, later learned via ranking model), user‑group clustering (using TGI), and user‑vote based ranking for authoritative lists.

Ranking models: Configurable pipelines allow feature transformation, model selection, optimizer choice, and model export. Both offline training and online serving share the same configuration, ensuring consistency.

Initial ranking used Edge Rank (Facebook) weighting different user actions; later LR was adopted for interpretability, followed by GBDT, GBDT+LR, FM, and finally deep learning models (Wide&Deep, DeepFM) using TensorFlow Estimator and feature columns.

Strategy Layer

To explore user interests and new items, online methods use UCB and Thompson Sampling, reserving slots for premium placements when needed.

Online Layer

Deep learning ranking runs on TensorFlow Serving, reducing development effort but incurring network overhead for feature transmission. Traditional machine‑learning ranking is embedded directly in the engine, saving network cost and providing a fallback when TF Serving fails.

Performance Comparison

After deployment, CTR improved as shown below:

Business Layer

From the user perspective, each recommendation scenario (e.g., homepage first‑screen, similar‑app suggestions) has distinct design and requirement nuances, affecting recall and ranking priorities.

Coordination & Scheduling Layer

Data flows between layers form a closed loop: real‑time log collection, item feature updates, user portrait refreshes, and model redeployment are all synchronized.

Analysis & Monitoring Layer

Self‑service query platforms and dashboards enable non‑technical staff to analyze data, while ELK‑based monitoring visualizes core system metrics for rapid issue detection.

Conclusion and Outlook

There is still a long way to go in machine learning. Future work includes deeper business scenario understanding, further modularization of feature and deduplication servers, exploration of image‑based features, and continual model architecture innovation. Both academic and industrial advances provide valuable ideas, but must be adapted to the specific data and problems of the app store to achieve business goals.

References

[1] He X, Pan J, Jin O, et al. Practical lessons from predicting clicks on ads at Facebook. KDD 2014. [2] Cheng H‑T, Koc L, Harmsen J, et al. Wide & deep learning for recommender systems. arXiv 2016. [3] Guo H, Tang R, Ye Y, et al. DeepFM: A Factorization‑Machine based Neural Network for CTR Prediction. 2017. [4] Zhou G, Song C, et al. Deep Interest Network for Click‑Through Rate Prediction. arXiv 2017. [5] Covington P, Adams J, Sargin E. Deep Neural Networks for YouTube Recommendations. RecSys 2016.