How Component‑Based Automation Transformed Activity Development with the Noah Platform

In many product teams, activity projects start with a simple request like “launch an event the day after tomorrow,” leading to repeated cycles of requirement review, development, testing, release, and eventual shutdown. These cycles often take 4‑5 days to several weeks, causing duplicated work, lengthy processes, customer complaints, and difficulty scaling.

Template Era

To address these issues, a template‑based approach was introduced. By standardizing common conditions and prize configurations, product managers can modify tasks and select prizes in the backend, while designers update page skins, allowing a new activity to go live with minimal effort.

However, developing a template adds extra effort (approximately 8 days total) and creates pressure due to high reuse expectations.

Noah Challenges

The need for finer‑grained reuse led to the creation of the Noah system, a component‑based, drag‑and‑drop solution for building activities.

Noah System Overview

Noah structures activities as multiple pages, each containing ordered components. Each component includes:

Basic component information (instance ID, version, etc.)

Configuration data (e.g., image URLs, prize probabilities)

Direct output data (dynamic content displayed with the page)

Initialization methods (actions run at activity start)

API interfaces for user interactions

Timers for scheduled tasks

Supporting services such as a Component Manager, Checker, Actioner, and Behavior Data collector enable component management, business closure, and large‑scale reuse.

How Noah Works

When a user accesses a URL, the system extracts a unique activity ID to locate the default page (or a specific page if an ID is provided). The front‑end, built on a Node.js framework, requests data from a PHP service, merges it with HTML templates, and renders the page.

Key data structures include:

actConf : activity‑level settings like start/end times.

pageInfo.components : ordered array of component objects.

component.config : component configuration (may contain sensitive info, filtered before front‑end use).

component.indexData : real‑time output data fetched via a callback.

component.componentSelect : basic component metadata (instance ID, version).

The front‑end iterates through components, loading their templates, CSS, and data to render the complete activity page.

Trigger Actions

Interactive components expose a fixed API. When a user clicks a button, the front‑end sends an AJAX request with the component instance ID, allowing the back‑end to retrieve configuration, evaluate checkers, and execute actions.

Checkers evaluate conditions (e.g., "today's flowers > 3 && total spend > 100"). Actions (Actioners) perform tasks such as granting virtual currency or issuing coupons. Expressions like #{C1} are transformed into method calls (e.g., self::runCheckerById(1) ).

Data Reporting

Each component defines reporting logic that sends HTTP calls with parameters (UserId, ActivityId, ComponentId, Time, P1‑P4) when specific actions occur. This enables business‑level analytics, such as tracking the distribution of virtual currency rewards from a “smash‑egg” component.

Conclusion

Noah has enabled mass production of activity projects, demonstrating measurable revenue growth through frequent activities. While the system meets current product needs, future work includes multi‑project integration, cross‑page linking, and deeper data analysis.