How Xianyu Doubled Its CTR through a Non-Invasive and Scalable IFTTT System
By Jianxin.
In the Xianyu app ecosystem-which is Alibaba’s major second-hand buy-sell platform in China-you can find all sorts of relationships. You could say that the relationship that is most apparent in the ecosystem, of course, is the one between buyers and sellers. This sort of relationship is triggered by the buyer showing interest in the item the seller has posted through his or her interaction with the item and buyer, specifically through actions such as searching for the item, favoriting it, or chatting with the seller. Another major type of interaction in the Xianyu app ecosystem is the relationships that exist between users and the platform itself. With these, however, there are some technical difficulties to overcome:
- User-generated relationships could be improved to be more information rich and be of greater variety. Currently, the existing system only maintains some user relationships, including favorites and likes, where other information is usually discarded or not recorded.
- The relationship between users is unidirectional-buyers can easily contact sellers, but the opposite doesn’t occur currently-and often the other users may be offline.
For the current system working behind the scenes on Xianyu, you can think of it all as a matter of conditions that trigger corresponding actions. You can confront the issues discussed above when this paradigm is enriched with the concept and service of IFTTT.
The Concept of IFTTT
IFTTT is a free web-based service that uses a type of concept called “Network Automation Artifact”. Generally speaking, it’s a relationally practical and simple concept. “IFTTT” is a crafty little abbreviation of the phrase “If This Then That”, which just means that if a “this” condition is met, a “that” action is triggered. Conceptually, then, “IFTTT” consists of three parts: a trigger (being “this”), an action (being “that”) and a recipe (being the entire condition-result clause set).
The concept behind IFTTT itself is not complex. Rather, the real magic of IFTTT lies in the complexity resulting from the combination of these simple components. That is, of course, to say that, when many simple IFTTT processes are connected with each other, a state machine spanning the entire Internet can be formed, with multiple platforms and multiple devices involved and impacted.
How IFTTT Can Work in Xianyu
IFTTT in the Xianyu app ecosystem can be generated based on the combination of several service scenarios and the IFTTT concept. In the Xianyu ecosystem, the IFTTT standard protocol can be encapsulated, which can make for a non-invasive and scalable service orchestration system.
The two main features of the IFTTT system implemented in Xianyu correspond to the above two problems:
- Multidimensional User Relationship Awareness
By “Multidimensional”, what is meant is coverage of several different kinds of user interactions. That is, the system of IFTTT used at Xianyu is one that both abstracts and also enriches user relationships through the collecting information about a larger range of dimensions. Then, based on richer user relationship data, the team at Xianyu can generate better user profiles and also reach users on the platform in a more effective manner.
- Real-Time and Bidirectional User Interaction
The IFTTT system on Xianyu also provides efficient storage and processing capabilities for data collected on user relationships at the underlying layer, which in turn also supports real-time processing of user relationships in upper-layer services. Next, this system also supports bidirectional relationships between the seller and buyer.
The IFTTT system on Xianyu can switch previous interactions between the platform and users and connections between buyers and sellers into natural interactions between various Xianyu users. All of this, in practical terms, makes for a better overall experience in the app ecosystem for everyone. All of this was designed based on the technical scenario that will be discussed in the following section:
IFTTT and Xianyu: The Technical Solution
Now let’s consider the technical scenario and solution that is involved at Xianyu. For this solution, the service is modeled according to the IFTTT specification, which is further divided into the Channel (think “relationships”, “directions”, and “dimensions”, so on), Trigger, and Action layers. Generally speaking, as you can see from the graphic above, the Channel layer is the underlying data layer. It associates the Trigger and Action layers to form the resulting Recipe. Below is a more detailed explanation of each of these layers:
- Channel: The function of the Channel layer in the IFTTT system of is to save and manage user relationship data. The layer defines the metadata structure of user relationships, including the relationship type, the source account, and the target account. The Channel layer is the cornerstone of the IFTTT system at Xianyu. The Trigger and Action layers further abstract the service logic based on user relationship data.
- Trigger: A Trigger is a custom trigger event on the service, which is closely related to the service. It may be that the person you have followed updates new items, the price of the item you have browsed is reduced, or the winners of a prize draw event you have participated in are announced. When a Trigger is triggered, the IFTTT system computes the user list based on the Trigger type and the configured relationship type, and calls the Action layer for processing.
- Action: The Action layer processes the user list computed after a Trigger is triggered. You can send Push notifications, entitlements or other custom items to the users in the list. An Action itself is a standardized and pluggable component. In a service, you can use the Action component to perform an AB test on the user list to quickly experiment with different Action policies.
Consider the detailed diagram below, which outlines the technical solution of the IFTTT system used for Xianyu:
The overall technical solution, shown above, has been refined based on the structure diagram of service modeling, to supplement the dependent technical components. Although the overall process is not described in detail here, detailed descriptions about the key modules in the process are given below:
Quick Scenario Access
The quick scenario access module is one of the most important modules of the system. The purpose of designing such a module is make services on Xianyu work seamlessly so everything appears to work in relative real-time for app users. Because in the initial design, the scenario access is used to report the service data and scenarios by adding Aspect-Oriented Programming (AOP) in the service logic. However, this method doesn’t provide the best overall experience as it increases the response times of service operations and it work well for all scenarios.
The quick scenario access module solves these problems. First, for this module, Log Service is used to access the massive network request logs of all applications to record the request addresses, parameters, and responses. Next, Log Service is used as the data source for Blink StreamCompute tasks. Network request addresses and parameters are filtered in real time according to the rules dynamically distributed by Diamond, and the data is assembled according to the specified format and reported to the Channel layer.
The quick scenario access solution decouples service logic from scenario access. It supports quick access, flexible changes, and low latency, and is a high-performance solution for big data scenario access.
Compute the User List Module
Next, there is the module for computing lists of users, which adopts the responsibility chain model, because in different Trigger scenarios, the computing and filtering logic of the service to the user list are different. With the responsibility chain model, then, the main process is decoupled from the service filtering logic, and various services are supported to flexibly customize the filtering logic without interfering with each other.
PushAction Module
Next, following this, the Action layer is the most important part of the IFTTT system implemented at Xianyu. It can reach the users directly. The Action logic can directly affect user activity and their overall feelings and experience about the app and ecosystem in general. The Push message is the most common logic in the Action layer, and it is necessary to prevent users from being harassed. The PushAction logic is as follows:
- Filters sensitive people;
- Checks the fatigue of the user;
- Conducts AB tests on the senders;
- Assembles messages;
- Synchronizes logs of each Action node to SLS, for easy retrieval and troubleshooting;
- Collects sending data and clicking data of messages to provide a basis for subsequent service decisions;
Fatigue
“Fatigue” for the IFTTT system at Xianyu is the key concept in preventing users from feeling they are being harassed by the system-or, to put it more bluntly, receiving too many message notifications from the app. At the Xianyu team, they designed fatigue into the three layers discussed above. The first layer is user-level fatigue, which controls the number of messages a user receives in a cycle. The second layer is the service dimension fatigue, which controls the number of messages that a user receives for a service in a cycle. The third layer is the target-level fatigue, which controls the number of messages that a user receives from the same sender in a cycle.
At the service dimension layer, flexible control of joint fatigue of multiple services is supported to ensure that users will not be unduly harassed by messages.
User Relationship Storage
User relationship data is one of the most important aspect of the IFTTT system implemented on Xianyu. It features a large storage capacity, being several terabytes in size. Next, it requires high performance for both storage and query operations, with transaction and queries per second values being well above 10,000 during peak hours for the app. After much research, the Xianyu team found that the Lindorm database developed within Alibaba Group could meet all of these requirements.
Lindorm is a high-performance KV storage database independently developed by Alibaba based on Hbase. It optimizes both the performance and stability of Hbase to some extent. The IFTTT system of Xianyu uses Lindorm as the storage of user relationship data. Performance tests show that the queries per second recording for data reading can get up to 70,000, and the transactions per second recording for data storage can be over 100,000. Lindorm has excellent performance and has lain the foundation for the high performance of IFTTT.
So What Are the Benefits of the IFTTT System
Since its launch, the IFTTT system for Xianyu has helped by providing additional support for multiple service scenarios. Moreover, it can help to provide near real- or real-time and bidirectional interactions and connections between buyers and sellers in the Xianyu platform. On average, it can process hundreds of millions pieces of relational data every day. The amount of processed Triggers can get up in the tens of millions, and the amount of processed Actions can get into the hundreds of millions. The Message CTR is more than doubled compared to that of offline Push.
The IFTTT system at Xianyu currently supports user interaction scenarios. In the future, the team at Xianyu plan to combine the service features of IdleFish itself to abstract IFTTT in a higher dimension and encapsulate the standard Recipe interface, turning the IdleFish IFTTT into a service platform that provides process orchestration and management capabilities.
IFTTT systems have already enjoyed much popularity outside of China-being implemented in the backbones of many systems used by major tech giants. So by no means Alibaba is not alone in this regard. In fact, since its launch in 2010, IFTTT has been used extensively. Several tech companies and teams alike have been using in both Internet and IoT fields. Although the concept of IFTTT is simple, it can help meet the high demands of users through standardized protocols, enabling various Internet products to serve users. This also gives the Internet practitioners at Xianyu and Alibaba in general some ideas ideas: In the face of new opportunities, is it more important to invest quickly? Or is it more effective to solve a type of problem by abstracting standard protocols?
Glossary
- SLS: https://cn.aliyun.com/product/sls
- Diamond: a persistent configuration management middleware developed by Alibaba;
- Blink: https://data.aliyun.com/product/sc
- MetaQ: a distributed, queue-based, and message-oriented middleware developed by Alibaba;
- Lindorm: a new generation of distributed NoSQL database developed by Alibaba based on HBase. Similar Alibaba Cloud products: https://www.aliyun.com/product/ots ;
- Tair: a high-performance, distributed, scalable, and highly reliable Key-Value structured storage system developed by Alibaba
