Message pushing method and system based on mobile internet user behavior analysis

Abstract

The invention relates to a message pushing method and system based on mobile internet user behavior analysis. The system comprises an SDK (Software Development Kit) and a server. The SDK is embedded in terminal equipment, and when a user enters a specific area, the SDK collects scene information and user behavior information; the server is used for judging whether to trigger a preset geographic fence or not based on the geographic position information of the terminal equipment and judging whether the user enters a specific area or not; when the user enters a specific area, screening and forming a to-be-pushed message set based on the scene information and the user behavior information; and sending the message with the highest score in the to-be-pushed message set to the terminal equipment so as to form visual processing through the SDK.

Description

Technical Field

[0001] This invention relates to the field of message push technology, and in particular to a message push method and system based on mobile Internet user behavior analysis. Background Technology

[0002] Currently, mobile internet technology is developing rapidly, and smartphone functions are constantly innovating, making mobile phones an integral part of people's lives. Mobile media has become the fifth largest media after newspapers, radio, television, and the internet. E-commerce and tourism based on the mobile internet are also developing rapidly, and people's online shopping behavior and lifestyles are quietly changing. However, problems such as low service quality, incomplete information, and insufficient personalized services have become important factors restricting the development of these industries. Therefore, there is an urgent need for an efficient recommendation method to solve these problems.

[0003] Location services, also known as mobile location services, obtain the location information of mobile terminal users through the networks of telecommunications mobile operators (such as GSM and CDMA networks). Location services integrate mobile communication technology, spatial positioning technology, Geographic Information System (GIS) technology, distributed computing technology, embedded database technology, and internet technology, belonging to a high-tech industry. Today, the business scope of location services covers multiple industries, including personal location information services, related information queries, POI queries, route planning, real-time navigation, logistics management, emergency rescue, weather condition queries, and traffic information queries. Location-based services can utilize the hardware and software resources of telecommunications operators to obtain the geographical location information of mobile terminal users, such as geographical coordinates. With the support of GIS system platforms, these services can bring corresponding economic growth.

[0004] Traditional content-based and location-based message recommendation technologies suffer from numerous drawbacks, such as excessive information load, limited useful information, and low message push accuracy, resulting in less than ideal recommendation results. Users primarily rely on methods like check-ins and queries to obtain information. Context-based and user behavior-based recommendation systems can overcome the shortcomings of traditional systems while more effectively alleviating the information overload problem faced by users. By combining the user's current context and behavioral characteristics for context-appropriate push notifications, information more closely aligned with their current situation can be recommended. Furthermore, by combining collaborative filtering algorithms with user profiling, the targeting and relevance of push services are further enhanced, meeting users' needs for personalized information and avoiding the indiscriminate and overwhelming nature of traditional message push methods.

[0005] Precise and personalized push notifications not only help enhance the brand value of information and clients but also improve user satisfaction. However, invalid information often triggers strong user resentment. Therefore, in addition to focusing on the speed of information dissemination, the quality of information content, and the user experience of the application, push notifications also require mastering appropriate methods and techniques. Building a cloud push platform that supports secure third-party access, has good performance, and high reliability is the foundation for achieving efficient push notifications. To ensure the quality of push services, the performance, reliability, and security of the cloud platform must be comprehensively considered. The Reactor pattern is an important concept in server design. It uses event-driven mechanisms to demultiplex and dispatch service requests from one or more clients, and processes multiple requests received simultaneously in a synchronous and orderly manner.

[0006] CN110415012A discloses a method, apparatus, device, and readable storage medium for determining dynamic scene areas. The method includes: acquiring location information of multiple shops; determining the corresponding electronic fence for each shop based on its location information and preset electronic fence parameters; merging the electronic fences for each shop to obtain multiple clustered areas; acquiring population density data for each clustered area, filtering each clustered area based on the population density data, determining the filtered clustered areas as dynamic scene areas, identifying terminal devices within the dynamic scene areas, and pushing messages to the terminal devices within the dynamic scene areas. This technical solution constitutes an ineffective method of sending information, uniformly sending information to all terminal devices entering the designated area. This unfiltered information does not enhance user satisfaction but rather reduces it.

[0007] Furthermore, on the one hand, there are differences in understanding among those skilled in the art; on the other hand, the applicant studied a large number of documents and patents when making this invention, but due to space limitations, not all details and contents were listed in detail. However, this does not mean that the present invention does not possess the features of these prior art. On the contrary, the present invention already possesses all the features of the prior art, and the applicant reserves the right to add relevant prior art to the background art. Summary of the Invention

[0008] Current geofencing systems generally rely on simplified two-state determination logic, which determines the device status by comparing the real-time distance D with the fence radius R: when D is less than or equal to R, it is considered to have entered; otherwise, it is considered to have left. However, this method has several shortcomings. For example, due to the inherent errors of positioning technologies such as GPS and BeiDou, when a device moves near the fence edge (D is close to R), the location data fluctuates frequently, causing the system to repeatedly misjudge between entering and leaving states, resulting in invalid requests and business anomalies, such as duplicate message pushes or incorrect attendance records. Furthermore, the system lacks a buffer mechanism and secondary verification process for boundary transition zones; even a small offset in single positioning data can trigger a state switch, leading to a high false trigger rate and insufficient stability. In addition, the system cannot accurately identify whether a device is stably within the fenced area or merely hovering at the boundary, thus requiring continuous high-precision positioning and the inability to dynamically optimize the sampling frequency based on the actual scenario, ultimately resulting in a significant increase in the power consumption of terminal devices.

[0009] To address the shortcomings of existing technologies, this invention provides a message push system based on mobile internet user behavior analysis. The system includes an SDK and a server. The SDK is embedded in the terminal device. When a user enters a specific area, the SDK collects scene information and user behavior information. The server determines whether a preset geofence is triggered based on the terminal device's geographical location information and whether the user has entered the specific area. When a user enters the specific area, the system filters and constructs a set of messages to be pushed based on the scene information and user behavior information. The message with the highest score in the set of messages to be pushed is sent to the terminal device for visualization processing via the SDK.

[0010] This design addresses the frequent state switching issues caused by GPS positioning errors in traditional geofencing by employing a three-level state determination rule (entering, present, leaving) for the geofencing area, thus avoiding invalid requests and business anomalies. A user behavior-based scoring algorithm enables precise personalized push notifications, effectively avoiding the haphazard, needle-in-a-haystack approach to push notifications. The system adopts a closed-loop optimization mechanism, continuously improving push notification effectiveness through user feedback, enhancing user satisfaction. Simultaneously, intelligent adjustment of the positioning sampling strategy significantly reduces terminal device power consumption, achieving a balance between push notification accuracy and system performance. This design not only improves the accuracy of information push notifications and user satisfaction but also optimizes system resource utilization efficiency, providing reliable technical support for personalized services in mobile internet scenarios.

[0011] According to a preferred embodiment, the step of the server determining whether a user has entered a specific area includes: comparing the geographical location of the terminal device with a preset geofence, calculating the spherical straight-line distance between the geographical location of the terminal device and the center point of the geofence based on the Haversine spherical formula, comparing the spherical straight-line distance with a preset fence radius, and determining the user's behavior status in relation to the specific area based on a three-level state determination rule; the behavior status includes entering, being in, and leaving the specific area (fenced area).

[0012] This technical solution employs Haversine's spherical formula to accurately calculate geofence distances, resolving the Earth's curvature error problem inherent in traditional planar distance calculations. A three-level state determination rule (entering, being in, leaving) replaces the simple two-state model for the fenced area, effectively avoiding high-frequency boundary jumps caused by positioning errors. The introduction of the "being in" fenced area allows the system to distinguish whether a device is stably located within the fence or merely moving at the boundary, thus intelligently adjusting the positioning sampling strategy and reducing terminal power consumption. Simultaneously, the precise comparison between the spherical distance and the fence radius ensures the reliability of state determination and reduces false triggering rates.

[0013] According to a preferred embodiment, the server's three-level state determination rule for determining whether a user has entered a specific area includes: setting a step size threshold Δd, setting the fence radius to R, and setting the spherical straight-line distance between the geographic location and the center point of the geofence to d; being in the fenced area: when d≤R-Δd, the current geographic location is determined to be in the core area inside the geofence, triggering services within the specific area; entering the fenced area: when R-Δd<d≤R+Δd, the current location is determined to be in the transition area of ​​the geofence boundary, and the server starts continuous positioning sampling. If the continuous sampling results all satisfy d≤R+Δd, then it is confirmed that the user has entered the fenced area, triggering an area entry event; leaving the fenced area: when d>R+Δd, the current location is determined to be in the area outside the geofence. If the previous determination state was being in the fenced area or entering the fenced area, then an area leave event is triggered.

[0014] This design effectively solves the problem of high-frequency boundary jumps caused by positioning errors by introducing a step size threshold Δd to construct a boundary buffer. When the device is in the transition zone from R-Δd to R+Δd, the system initiates continuous positioning sampling confirmation to avoid misjudgments caused by single positioning drift. Being in the fenced area (d≤R-Δd) indicates that the device is stable in the core area, and the sampling frequency can be reduced; the states of entering and leaving the fenced area require continuous confirmation, which significantly reduces the false trigger rate. This design enables the system to intelligently distinguish whether the device is stably located within the fence or only moving at the boundary, which not only ensures the reliability of state determination, but also significantly reduces terminal power consumption by dynamically adjusting the positioning strategy.

[0015] According to a preferred embodiment, the step of the server filtering and forming a set of messages to be pushed based on scene information and user behavior information includes: when the terminal device enters a preset geofence area, the SDK collects multi-dimensional information of the user and the terminal device and sends it to the server; the server calculates the score of each message based on the user profile, scene information, user behavior information and filtering algorithm, selects information that the user is interested in based on a preset threshold, and forms a set of messages to be pushed that the user is interested in.

[0016] This technology achieves precise targeting through multi-dimensional information fusion, avoiding the indiscriminate approach of traditional geofencing-based push notifications. When a user enters a specific area, the system not only obtains location information but also performs a comprehensive analysis combining user profiles, real-time scenarios, and current behavior. Through a scoring algorithm, the system intelligently filters out personalized content that users are truly interested in, while filtering out irrelevant messages. This design avoids the user experience problems of relentless marketing and significantly improves push conversion rates, ensuring that push content highly matches user needs and achieving precise marketing results through timely and relevant push notifications.

[0017] According to a preferred embodiment, the step of the SDK collecting user ratings for messages includes: assigning different weights to different user behaviors, and performing a weighted calculation of the weights based on user behavior information; wherein, rating = message opening behavior weight × A + message browsing time weight × B + user active interaction behavior weight × C; A, B and C are weight coefficients.

[0018] This scoring mechanism accurately quantifies users' interest in messages through multi-dimensional behavioral weighting. The system assigns different weights to message opening behavior, browsing time, and proactive interaction, dynamically calculating scores based on actual behavioral data. Message opening behavior is judged using binary criteria, browsing time is normalized by comparing it to the average duration of similar messages, and proactive interaction is determined by its presence or absence. This design ensures that the score truly reflects user interests, avoiding the bias of a single indicator. The scoring results are used to filter high-value messages, supporting precise push decisions, while also providing objective feedback data to drive continuous optimization of the recommendation algorithm, significantly improving push accuracy and user experience.

[0019] According to a preferred embodiment, the server also performs an overall evaluation of the recommendation effect of the information from multiple dimensions; wherein, the multiple dimensions of the overall evaluation include the click-through rate dimension, the average rating of the message dimension, and the interaction rate dimension; the higher the click-through rate, the average rating of the message, and the interaction rate, the better the recommendation effect.

[0020] This multi-dimensional evaluation mechanism comprehensively quantifies recommendation effectiveness through three core metrics: click-through rate (CTR), average message rating, and interaction rate. CTR reflects initial user interest, average rating reflects the true value of the content, and interaction rate measures the depth of engagement. The synergy of these three metrics avoids the bias of a single indicator. Based on this, the system dynamically optimizes its recommendation strategy. For example, when the average rating is high but the CTR is low, the content presentation can be adjusted; when the interaction rate is abnormal, content quality issues can be quickly identified. This closed-loop evaluation not only accurately identifies high-quality content but also provides objective data support for algorithm iteration, significantly improving push conversion rates and user stickiness. It upgrades the recommendation system from passive response to intelligent optimization, ultimately achieving a dual improvement in user satisfaction and commercial value.

[0021] According to a preferred embodiment, the communication connection between the SDK and the server includes: the SDK generating a unique identifier (CID) for the terminal device; the SDK establishing a bidirectional channel with the server to send the scene information and user behavior information it collects, and to receive personalized messages pushed to the server.

[0022] This design achieves precise binding between terminals and servers by generating unique device identifiers (CIDs), ensuring that communication data from each device can be accurately tracked and processed. The establishment of a bidirectional communication channel enables the SDK to upload user behavior data and receive personalized messages in real time, providing a foundational data stream for system analysis. This design avoids the limitations of traditional one-way communication, ensuring the integrity of data collection while supporting instant message push, allowing the system to dynamically optimize recommendation strategies based on real-time feedback. Simultaneously, the unique identifier mechanism effectively prevents data confusion, significantly improving the accuracy of message pushes and the user experience.

[0023] The present invention provides a message push method based on mobile Internet user behavior analysis from a second aspect. The method includes: when a user enters a specific area, an SDK collects scene information and user behavior information and sends them to a server; the server determines whether a preset geofence is triggered based on the geographical location information of the terminal device, and determines whether the user has entered the specific area; when a user enters the specific area, a set of messages to be pushed is filtered and constructed based on scene information and user behavior information; the message with the highest score in the set of messages to be pushed is sent to the terminal device to form a visualization processing through the SDK.

[0024] This method effectively addresses the high-frequency boundary transitions caused by GPS positioning errors by using a three-level geofencing status determination (entering, present, leaving) to determine the geofence's status, thus avoiding invalid state transitions. Combining scene information collected by the SDK with user behavior data, the system employs a weighted scoring algorithm to accurately filter high-value content. This design ensures that the pushed content highly matches the user's real-time needs, significantly reducing false trigger rates and terminal power consumption, while continuously optimizing recommendation quality through closed-loop feedback. Ultimately, this improves push accuracy and significantly increases user conversion rates.

[0025] According to a preferred embodiment, the step of determining whether a user has entered a specific area includes: comparing the geographical location of the terminal device with a preset geofence, calculating the spherical straight-line distance between the geographical location of the terminal device and the center point of the geofence based on the Haversine spherical formula, comparing the spherical straight-line distance with a preset fence radius, and determining the user's behavior status in relation to the specific area based on a three-level state determination rule; the behavior status includes entering, being in, and leaving the specific area.

[0026] This step uses Haversine's spherical formula to accurately calculate the straight-line distance on the sphere, avoiding the Earth's curvature error in planar distance calculations. A three-level state determination replaces the simple two-state model, effectively solving the problem of high-frequency boundary jumps caused by positioning errors. Being within the fenced area indicates that the device is stably in the core area; entering and leaving the fenced area requires continuous confirmation, significantly reducing the false trigger rate.

[0027] According to a preferred embodiment, the three-level state determination rule for determining whether a user has entered a specific area includes: setting a step size threshold Δd, setting the fence radius to R, and setting the spherical straight-line distance between the geographic location and the center point of the geofence to d; being in the fenced area: when d≤R-Δd, the current geographic location is determined to be in the core area inside the geofence, triggering services within the specific area; entering the fenced area: when R-Δd<d≤R+Δd, the current location is determined to be in the transition area of ​​the geofence boundary, and the server starts continuous positioning sampling. If the continuous sampling results all satisfy d≤R+Δd, then it is confirmed that the user has entered the fenced area, triggering an area entry event; leaving the fenced area: when d>R+Δd, the current location is determined to be in the area outside the geofence. If the previous determination state was being in the fenced area or entering the fenced area, then an area leave event is triggered.

[0028] This method constructs a boundary buffer using a step size threshold Δd, effectively addressing the problem of high-frequency boundary jumps caused by positioning errors. The three-level decision-making rules enable the system to accurately distinguish whether a device is stably located within the fence or only moving at the boundary, ensuring the reliability of state determination while significantly reducing terminal power consumption through dynamic adjustment of the positioning strategy. Attached Figure Description

[0029] Figure 1 This is an overall schematic diagram of the message push system based on mobile Internet user behavior analysis provided by the present invention; Figure 2 This is a schematic diagram of the message push method based on mobile Internet user behavior analysis provided by the present invention; Figure 3 This is a logical schematic diagram of the push server provided by the present invention; Figure 4 This is a flowchart of the geofencing management process provided by the present invention; Figure 5 This is a schematic diagram illustrating the interaction between the message push system based on mobile internet user behavior analysis provided by this invention and a third party.

[0030] List of reference numerals 100: SDK; 200: Server; 300: Terminal device; 110: Pre-compiled library; 120: API interface specification; 130: Development toolchain; 140: Technical documentation; 150: Sample code. Detailed Implementation

[0031] The following is a detailed explanation with reference to the accompanying drawings.

[0032] The key technical challenges currently facing recommendation systems include information overload leading to sparse effective content, lack of context awareness causing recommendations to detach from real-time situations, insufficient personalization capabilities resulting in recommendation generalization, and low push accuracy leading to inefficient interference. Traditional content- and location-based recommendation methods suffer from severe information redundancy, low proportion of effective content, and insufficient push accuracy, forcing users to rely on check-ins or manual queries to obtain information. In contrast, recommendation systems that integrate scene awareness and user behavior analysis capture the user's context and behavioral characteristics in real time, enabling precise and context-sensitive pushes to meet current needs. They also integrate collaborative filtering algorithms and refined user profiles to improve the targeting and personalization of pushes, thereby effectively avoiding the flood of invalid information (such as the inefficient needle-in-a-haystack approach) and excessive interference (such as indiscriminate bombardment of pushes).

[0033] To address the shortcomings of existing technologies, this invention provides a message push system and method based on mobile internet user behavior analysis. This invention also provides a server 200 for pushing messages based on mobile internet user behavior analysis.

[0034] A message push system based on mobile internet user behavior analysis includes an SDK100 (Software Development Kit) and a server 200. The SDK100 is embedded in a terminal device 300. The communication connection between the SDK100 and the server 200 includes: the SDK100 generating a unique identifier (CID) for the terminal device 300; and the SDK100 establishing a bidirectional channel with the server 200 to send collected scene information and user behavior information, and to receive personalized push messages. The SDK100 provides new message notifications through three methods: notification bar alerts, in-app pop-ups, and plain text.

[0035] SDK100 is an integrated toolset used to encapsulate underlying system functions and accelerate application building. It includes core components such as pre-compiled libraries (110), API interface specifications (120), development toolchains (130), technical documentation (140), and sample code (150). Figure 1 As shown. The core value of SDK100 lies in transforming system-level functions (such as the Settings.Secure.getString() method provided by Android SDK100) into directly callable interfaces. This allows developers to obtain the device's unique identifier, ANDROID_ID (a 64-bit value generated when the system first starts), without having to deal with the underlying data storage mechanism. This efficiently supports bidirectional communication for data collection and personalized message push. The essential difference between SDK100 and APIs is that APIs define the contract specifications for service interaction, while SDK100 provides a complete toolkit for implementing that contract. By abstracting complex logic (such as device identifier management), it significantly reduces development complexity.

[0036] Server 200 is configured as follows: When a user enters a specific area, SDK 100 collects scene information and user behavior information; Server 200 determines whether a preset geofence is triggered based on the geographical location information of terminal device 300, and determines whether the user has entered the specific area; when the user enters the specific area, it filters and constructs a set of messages to be pushed based on scene information and user behavior information; the message with the highest rating in the set of messages to be pushed is sent to terminal device 300 for visualization processing through SDK 100. Server 200 also determines the correctness of message push based on the value feedback and rating of the push information to the user.

[0037] This invention upgrades the technology to an intelligent service system through a three-layer innovation: closed-loop architecture design, dynamic data-driven approach, and scenario-based experience optimization. This fundamental leap from tool to system, combined with targeted solutions to the three major shortcomings of existing technologies, achieves a dual improvement in push accuracy and system performance.

[0038] Preferably, server 200 provides a web-based management interface, allowing third-party enterprise users to configure relevant parameters, add or delete messages to be pushed, and view message push-related data, such as success rate and accuracy. The web interface provides a user-friendly graphical interface that is simple and direct to operate.

[0039] For managing large volumes and frequent message push notifications, third-party enterprise users can leverage the Server SDK for flexible operation. Calling the `UBCServerSdk.init()` method initializes and runs the Server SDK. This creates a proxy object for server 200. This proxy object transmits data by sending HTTP requests to server 200. Third-party users can manage cloud platform data by interacting with this proxy object. For non-Java platforms, the REST API of server 200 can be directly called for message push settings and management.

[0040] Figure 3 The arrows in the diagram indicate the communication relationships between components and the protocols used (HTTP / MQTT), illustrating the message flow path between the server, push server, and multiple client terminals. For example... Figure 3 As shown, server 200 contains several server applications. The serial numbers of the server applications can be 1 to m. Each server application integrates an SDK server-side component to handle business logic and communicate with the push server.

[0041] like Figure 3 As shown, the push server acts as a message relay hub, receiving messages from the server application and pushing them to the client (Web or Android App) of the specified terminal device 300. The push server communicates with the network based on the HTTP protocol. A push server is a server specifically designed to implement real-time message push functionality; it acts like an information courier, responsible for quickly and accurately pushing messages from server 200 to the user's terminal device 300 without requiring the user to actively request them.

[0042] The client establishes a connection with the push server via the HTTP protocol to receive real-time messages. The terminal devices 300 are numbered from 1 to n. Each terminal device 300 has at least one client installed. Preferably, each Android application integrates an SDK client component. The SDK client component maintains a persistent connection with the push server via the MQTT protocol to achieve real-time message subscription and reception.

[0043] By encapsulating complex batch push logic (sharding, encryption, retries) into a simple interface, the solution addresses the issue of repetitive development of underlying capabilities by enterprises. Protocol optimization for large data volumes: Through the combination of HTTP / 2 and Protocol Buffers, it overcomes the performance bottleneck of traditional HTTP / 1.1, supporting efficient push of millions of messages. Full lifecycle controllability: It provides a complete interface chain from push to query to termination, enabling dynamic management of message pushes, whereas traditional solutions only support single pushes and lack subsequent control capabilities. These design features make this solution significantly superior to existing technologies in large-scale, high-frequency enterprise-level message push scenarios, demonstrating outstanding substantive characteristics and significant progress.

[0044] Multiple access methods provide users with different choices, greatly increasing the system's flexibility. The Android SDK and Server SDK provide well-encapsulated system interfaces, facilitating calls and reducing the workload for developers; for non-Java platforms, access can also be achieved by calling the REST API.

[0045] The steps of the message push method based on mobile internet user behavior analysis of the present invention are as follows: Figure 2 As shown.

[0046] S100: Load SDK100 and initialize its operation.

[0047] SDK100 obtains the ANDROID_ID by calling the Settings.Secure.getString() method provided by the Android system, and generates a unique identifier CID for device identification based on this.

[0048] The identifier CID corresponds to the 64-bit (16-character hexadecimal string, 8 bytes) ANDROID_ID generated when the system is first booted. The ANDROID_ID will be reset when the device performs a factory reset; otherwise, its value will remain permanently unchanged.

[0049] Based on its uniqueness and stability, the identifier CID is widely used for the precise identification of user information, effectively supporting accurate data collection and personalized message push services.

[0050] Settings.Secure.getString() is a core API method of the Android system, belonging to the android.provider.Settings.Secure class. It accesses the system security settings database through ContentResolver to retrieve the string value of a specified key.

[0051] S110: Dynamically request relevant permissions from terminal device 300.

[0052] Let's take a terminal device 300 running the Android system as an example. In the Android system, with the continuous strengthening of security mechanisms, applications need to dynamically request user authorization to access sensitive functions. For example, when obtaining location permission, the application first checks the current permission status using `ContextCompat.checkSelfPermission()`; if not granted, it calls `ActivityCompat.requestPermissions()` to initiate a permission request. If the user refuses authorization, the application can use the `shouldShowRequestPermissionRationale()` method to determine whether it needs to explain the necessity of the permission (e.g., location functionality is used to provide nearby services), explain the reason in a dialog box, and then trigger the permission request again. If the user agrees, the permission is successfully obtained and subsequent operations are executed; if the user continues to refuse, the application can guide the user to manually enable the permission in system settings, thereby ensuring the compliance of the permission acquisition process and optimizing the user experience.

[0053] These permissions mainly include:

[0054] In the terminal device 300 running the Android system, location information needs to be obtained through the LocationManager service.

[0055] First, the developer calls `getSystemService(Context.LOCATION_SERVICE)` to obtain a `LocationManager` instance. This service supports obtaining current coordinates, tracking device movement, and setting geofences, triggering corresponding alarms when the terminal device enters or leaves a specified area. Next, the developer needs to specify a location provider, such as `NETWORK_PROVIDER` (mobile network-based positioning) or `GPS_PROVIDER` (satellite-based positioning). After selecting a provider, the developer uses the `getLastKnownLocation()` method to obtain the most recent location data, including key parameters such as longitude, latitude, and speed.

[0056] Finally, the location is compared with a preset geofence. The main method used is the spherical straight-line distance calculation based on the Haversine spherical formula, which enables a high-precision comparison between the current location and the preset geofence to determine whether the location has entered, is within, or left the fenced area, such as a commercial district or tourist attraction.

[0057] In Android application development, developers first obtain a LocationManager instance by calling getSystemService(Context.LOCATION_SERVICE). This instance supports obtaining the current geographic coordinates, tracking the device's movement trajectory, and configuring geofences. Subsequently, a location provider needs to be specified (e.g., NETWORK_PROVIDER based on mobile network or GPS_PROVIDER based on satellite positioning), and core location data such as longitude and latitude are obtained through the getLastKnownLocation() method. To achieve high-precision area status determination, the application uses the Haversine spherical formula to calculate the spherical straight-line distance between the current location and the center point of the preset geofence, and compares it with the fence radius in real time. This accurately determines whether the device is entering, within, or leaving the geofence area, ensuring the accuracy and real-time performance of the geofence triggering logic.

[0058] S200: SDK100 collects scene information and user behavior information.

[0059] Preferably, the scene information includes location information, time, weather information, network information, and user device information. User device information includes the user's mobile phone brand and model, Android system version, current device battery level, and the number of times the device has been woken up in a recent period. User behavior information includes information about applications recently used by the user.

[0060] Preferably, access permissions are required to collect usage information from applications within the operating system of the terminal device 300. <uses-permission android:name="android.permission.PACKAGE_USAGE_STATS" / > .

[0061] Unlike obtaining location permissions, requesting this permission first requires obtaining an AppOpsManager object using the `getSystemService(Context.APP_OPS_SERVICE)` method, and then checking for the relevant permissions using the `checkOpNoThrow()` method. If not, a settings page will pop up, allowing the user to manually grant the permission. Finally, the relevant permissions are successfully obtained.

[0062] UsageStatsManager is a class provided in Android system version 5.0 and later to collect statistics on app usage. An instance of the UsageStatsManager class, usm, can be obtained through the Context.getSystemService(Context.USAGE_STATS_SERVICE) method.

[0063] The usm.queryUsageStat() and usm.queryEvents() methods can be used to retrieve usage data for all apps over the past day, week, month, and year.

[0064] like Figure 1 As shown, SDK100 sends scene information and user behavior information to server 200. Specifically, SDK100 encapsulates the collected scene information and user behavior information into a UBCDataInfo class, and then sends the collected scene information and user behavior information to server 200 in JSON format via the mobile network, where server 200 processes and analyzes it.

[0065] When terminal device 300 enters a preset geofence area, SDK 100 collects multi-dimensional information about the user and terminal device 300 and sends it to server 200. Server 200 calculates a score for each message based on user profile, scene information, user behavior information, and filtering algorithms, and selects information of interest to the user based on preset thresholds, forming a set of pushable messages of interest to the user. For example... Figure 1 As shown, server 200 sends the message with the highest score in the set of messages to be pushed to terminal device 300.

[0066] S300: Triggers geofencing, determines the current scene, and implements context-appropriate push notifications. The specific process is as follows: Figure 4 As shown.

[0067] S310: Preset geofence parameters and customize fences to create geofences.

[0068] The core parameters of the target geofence are pre-entered into the memory of the terminal device 300. These core parameters include the coordinates of the geofence center point, the effective radius of the geofence, and the judgment threshold.

[0069] The geofence center point coordinates are based on the WGS-84 coordinate system, recording the latitude and longitude values ​​of the center point. The effective radius of the geofence is set according to the application scenario (such as business districts, tourist attractions, transportation hubs, etc.), with the radius accuracy retained to one decimal place. The judgment threshold is used to compensate for errors caused by positioning signal fluctuations, with a default value of 1 meter.

[0070] S320: Obtain the geographic location and calculate the spherical straight-line distance based on Haversine's spherical formula.

[0071] This invention preferentially adopts the Haversine formula due to its dual advantages in spherical geometric modeling and numerical computation stability. The Haversine formula directly calculates great circle distances based on spherical trigonometry, fundamentally eliminating model errors caused by planar approximation methods over long distances or in high-latitude regions. Simultaneously, its unique semi-sine function form effectively avoids the computational failure problem caused by floating-point rounding errors in the traditional cosine law when two points are extremely close, thus ensuring extremely high accuracy and reliability of distance determination across the entire distance range.

[0072] Server 200 calls the positioning module of terminal device 300 to obtain the real-time location coordinates of terminal device 300, and then compares the geographical location of terminal device 300 with the preset boundary conditions of geofence. This comparison process is achieved by calculating the spherical straight-line distance between the real-time location and the center point of the geofence. Preferably, the spherical straight-line distance between the geographical location of terminal device 300 and the center point of the geofence is calculated based on the Haversine spherical formula.

[0073] Specifically, the straight-line distance on the sphere is calculated using the following mathematical formula.

[0074] 。

[0075] In the above formula, d represents the straight-line distance between two points on the sphere; R represents the average radius of the Earth, which is 6371 kilometers. and These represent the latitudes of the first point (the center point of the geofence) and the second point (the real-time location of the terminal device), respectively, in radians; Δφ= - λ1 = λ2 - λ1 represents the difference in latitude between two points; Δλ = λ2 - λ1 represents the difference in longitude between two points; λ1 and λ2 represent the longitudes of the first and second points respectively, in radians; sin 2 (θ) represents the square of the sine function of angle θ.

[0076] For example, the preset center point coordinates of the geofence are: latitude 39.9163°N, longitude 116.3903°E; the judgment radius of the geofence is 0.5 kilometers; the real-time location coordinates reported by the terminal device 300 are: latitude 39.9180°N, longitude 116.3920°E.

[0077] The calculation process by which server 200 determines whether terminal device 300 is within the fenced area is as follows.

[0078] S321: Coordinate transformation; that is, converting the degree units of geographic coordinates to the radian units.

[0079] Center point coordinate transformation: radian.

[0080] λ1 = 116.3903 × π / 180 ≈ 2.0313 radians.

[0081] Equipment point coordinate transformation: radian.

[0082] λ2 = 116.3920 × π / 180 ≈ 2.0314 radians.

[0083] S322: Calculate the coordinate difference. Calculate the latitude and longitude difference between two points.

[0084] Δφ= - ≈0.0000 radians; Δλ=λ2-λ1≈0.0001 radians.

[0085] S323: Calculate the intermediate variable 'a' in the formula using the Haversine formula.

[0086] a=sin 2 (Δφ / 2)+cos( )×cos( )×sin 2 (Δλ / 2).

[0087] a≈0+(0.7669×0.7669×0.0000000025)≈1.47×10 -9 .

[0088] S324: Calculate the central angle and the final distance.

[0089] Calculate the central angle c formed by the line connecting the Earth's center to the two points and the final straight-line distance d on the sphere.

[0090] radian; d = R × c = 6371 × 0.0000766 ≈ 0.488 km.

[0091] S325: Determine positional relationships.

[0092] The real-time location is approximately 0.488 kilometers away from the center point of the geofence, which is less than the preset judgment radius of 0.5 kilometers.

[0093] Therefore, server 200 determines that terminal device 300 is currently located within the geofence area. Through the above steps, an accurate determination of the spatial relationship between terminal device 300 and the geofence is achieved.

[0094] S330: Trigger geofencing.

[0095] The system compares the straight-line distance across the sphere with the preset fence radius and determines the user's behavior status in a specific area based on a three-level status determination rule. Behavior status includes entering, being in, and leaving the specific area.

[0096] Preferably, a step size threshold Δd is set, the fence radius is set to R, and the spherical straight-line distance between the geographic location and the center point of the geographic fence is set to d.

[0097] The three-level status determination rules for server 200 to determine whether a user has entered a specific area are as follows.

[0098] Within the geofence: When d ≤ R - Δd, the current geographical location is determined to be within the core area of ​​the geofence, triggering services within that specific area. Preferably, services within the specific area include, for example, push notifications for commercial district offers or loading of tourist attraction guide information.

[0099] Entering the geofenced area: When R-Δd < d ≤ R+Δd, the current location is determined to be in the transition zone of the geofence boundary. Server 200 initiates continuous location sampling. If multiple consecutive sampling results satisfy d ≤ R+Δd, entry into the geofenced area is confirmed, triggering an area entry event. Preferably, the sampling interval for continuous location sampling is, for example, 1 second / sample. The specific value of continuous location sampling is not limited and can be set according to requirements. The number of consecutive sampling results is preferably at least three. Preferably, the triggering area entry event is, for example, a check-in record or service permission activation.

[0100] Leaving the geofence: When d > R + Δd, it is determined that the current location is outside the geofence. If the previous determination state was within or inside the geofence, then a geofence departure event is triggered. Preferably, the geofence departure event is triggered by, for example, service pause or departure reminder push notification.

[0101] Existing geofence triggering mechanisms typically employ a simple two-state model, which determines the state based solely on a comparison between the real-time distance D and the fence radius R: when D≤R, it is determined to be the state of entering the fenced area, and when D>R, it is determined to be the state of leaving the fenced area.

[0102] However, the state model of the existing technology has significant drawbacks: First, due to the accuracy error of positioning technologies such as GPS (usually ranging from several meters to tens of meters), when the device moves near the fence boundary (D≈R), the continuous positioning coordinates will fluctuate frequently inside and outside the boundary, causing the system to repeatedly switch incorrectly between the state of entering and leaving the fence area, resulting in invalid requests and chaotic business logic (such as repeated push notifications or attendance records).

[0103] Secondly, there is a lack of a transition zone processing and confirmation mechanism for boundary states. An accidental drift of a single positioning point can trigger a state change, resulting in a high false trigger rate and poor reliability.

[0104] Thirdly, it is impossible to distinguish whether the device is stably located inside the fence or moving at the boundary. The system needs to always perform high-precision positioning at a high frequency and cannot intelligently adjust the sampling strategy according to the scenario, resulting in excessive power consumption of the terminal device.

[0105] In contrast, the core innovation of the present invention is: introducing a three-level state determination rule based on a step size threshold (Δd), expanding the geographical fence boundary from an absolute boundary to a transition area with a width of 2Δd (R - Δd < d ≤ R + Δd), and implementing a differential processing logic for different regions.

[0106] The advantages of the present invention are specifically reflected in: by setting a transition area and introducing a continuous positioning sampling confirmation mechanism for the state of entering the fence area, effectively filtering out the instantaneous jitter caused by positioning drift, significantly improving the accuracy and stability of state determination; by dividing the state into an internal core area, a boundary transition area, and an external area, only enabling high-frequency continuous positioning (such as once per second) in the boundary transition area, and using low-frequency regular positioning in the internal core area and the external area, realizing intelligent energy consumption management, optimizing system performance and reducing terminal power consumption; at the same time, the three-level state (entering, being in, leaving) of the fence area can more accurately describe the user's behavior intention and trigger events that fit the actual business scenario; for example, providing continuous services in the state of being in the fence area and recording key actions in the state of entering the fence area, thereby improving the intelligent level of location services and the user experience.

[0107] Preferably, the dynamically adjusted step size threshold (Δd) is associated with the positioning accuracy (σ).

[0108] To further optimize the anti-jitter effect and energy consumption, the step size threshold Δd is not a fixed value, but is dynamically adjusted according to the real-time positioning accuracy parameter σ reported by the terminal device 300.

[0109] Specifically, the formula for the server 200 to calculate the step size threshold is: .

[0110] In the above formula, k is a preset adjustment coefficient greater than 1 (the preferred value is 1.5 - 2.5). k is further preferably 1.5, 1.75, 2.0, 2.25, and 2.5. The positioning accuracy parameter σ is reported by the positioning module (such as GPS, Beidou) of the terminal device 300 together with the position coordinates, and its value is usually in meters, representing the confidence radius of the positioning point.

[0111] The advantage of this invention's dynamic adjustment of the step size threshold lies in its ability to adapt the width of the transition region to the quality of the positioning signal. When the positioning signal is good (small σ value), the transition region is narrower, resulting in a more sensitive decision response. When the positioning signal is poor (large σ value, such as in urban areas with tall buildings), the system automatically widens the transition region and may require more consecutive sampling confirmations. This ensures robustness of the decision-making even in harsh positioning environments, avoiding false triggers. This demonstrates the algorithm's adaptability to complex real-world environments, surpassing the simple logic of fixed parameters.

[0112] Preferably, the present invention includes a mechanism for maintaining the state of being within a fenced area and a low-frequency monitoring mechanism.

[0113] Once the user is determined to be in the fenced area, the server 200 will no longer continuously calculate the real-time distance D at a high frequency, but will switch to a low-frequency monitoring mode.

[0114] Maintenance Mechanism: Server 200 performs positioning sampling on terminal device 300 and calculates the spherical straight-line distance d1 at a first sampling interval T1 (e.g., 10 seconds); as long as d1≤R+Δd, server 200 remains in the fenced area. Only when d1>R+Δd will it switch back to the normal judgment process.

[0115] Low-frequency monitoring mechanism: In order to deal with the situation where users move within the fence, if the spherical straight-line distance d1 calculated by sampling N times (e.g., 2 times) during the low-frequency monitoring period all satisfy d1≤R-Δd / 2 (a more stringent internal threshold), then the server 200 will automatically extend the sampling interval to T2 (e.g., 30 seconds, and T2>T1).

[0116] This hold-and-monitor mechanism, combined with the low-frequency monitoring mechanism, effectively optimizes energy consumption: once a user is confirmed to be stable within the fence, the positioning frequency is significantly reduced; when a user shows a tendency to move towards the center of the fence, the monitoring frequency is further relaxed. This achieves a dynamic balance between system resource consumption and the accuracy of status monitoring, becoming a core optimization point for long-term, large-scale user services, and making a significant technological contribution.

[0117] S340: Receives trigger event broadcasts.

[0118] Terminal device 300 listens for and receives geofence event broadcasts from server 200 through a background service, performs security verification on the received data packets, and parses out the event type, fence identifier, and trigger timestamp information.

[0119] S350: Clear all fences, end.

[0120] After completing event parsing, the terminal device 300 removes the geofence configuration triggered this time from the activity monitoring list, releases the relevant location monitoring resources, and ends the current geofence monitoring process.

[0121] S400: Server 200 retrieves recent, time-sensitive data from users to enable message push based on historical scenarios.

[0122] Server 200 retrieves and analyzes user behavior data within a recent specific time window to construct historical scenarios, and based on this, implements highly personalized and timely message pushes. This method overcomes the limitations of traditional push notifications that are based solely on real-time location or simple user profiles, achieving a deeper understanding of user behavioral intentions.

[0123] In the above, "recent" is not a fixed time length, but a dynamically defined sliding time window based on the goals of the push strategy and the timeliness requirements of the data. Preferably, the dynamic time window mechanism includes the following two modes: Short-term window: Used to capture highly immediate behavioral intentions, such as data from the last 24 hours or the last 7 days. Suitable for scenarios such as restaurant recommendations and instant discounts.

[0124] Long-term window: Used to identify periodic behavioral patterns or long-term interests, such as data from the most recent month or quarter. Suitable for scenarios such as membership point reminders in shopping districts and seasonal product recommendations.

[0125] Server 200 can automatically select the matching time window range based on the type of push message.

[0126] The process by which server 200 retrieves data from the user behavior database (such as database 400 in the embodiment) is a multi-dimensional, targeted query process. The query involves filtering by time dimension, data type marking, geofence event records, business interaction records, and terminal sensor context data.

[0127] Time-based filtering: Based on the "recent" time window defined above, execute an SQL query or NoSQL query, with the condition that the data timestamp >= CURRENT_TIMESTAMP - [time window].

[0128] Data type tagging: This indicates that the retrieved data is structured data with a clearly defined context tag. This data was tagged with context tags during the initial data collection and storage. This mainly includes the following information: Geofencing event logs: such as entering the XX business district, leaving the XX office park, with timestamps and duration of stay.

[0129] Business interaction records: such as browsing the product details page of XX, adding product YY to the shopping cart, using ZZ service, etc.

[0130] Terminal sensor context data: such as being connected to the company's Wi-Fi (indicating a work scenario) or moving at night at a speed of less than 5 km / h (indicating a home or accommodation scenario).

[0131] In this invention, the historical scenario specifically refers to a situation with a specific behavioral intent or state that is abstracted by fusing and pattern recognition of multiple recent heterogeneous data (geographic location, business behavior, device context) of a user.

[0132] The scenario construction process for server 200 is as follows.

[0133] S410: Feature extraction.

[0134] Server 200 extracts key feature vectors from the retrieved recent data, such as: {Geographic location: business district A, Time: weekend evening, Behavior: stay in a restaurant for more than 30 minutes, Business: search for Sichuan cuisine}.

[0135] S420: Scene pattern matching.

[0136] Server 200 matches the extracted feature vectors with a predefined scenario pattern library. The scenario pattern library consists of typical scenario templates predefined through machine learning or rule engines, such as potential shopping demand scenario patterns and dining decision-making scenario patterns.

[0137] The rule for potential shopping demand scenario patterns is "having entered the same business district ≥ 2 times in the past 7 days and stayed for more than 1 hour, but without high-value transaction records".

[0138] The rule for the restaurant decision-making period scenario model is "recently (within 24 hours) located in a restaurant cluster area at the time of dining and having searched for or browsed restaurant brands".

[0139] S430: Scenario confidence assessment.

[0140] Server 200 calculates the degree of fit between the current user data and the matched scene pattern, generating a scene confidence score. If the score exceeds a preset threshold (e.g., 80%), it is determined that the user is currently in that historical scene.

[0141] The specific process of server 200 implementing message push based on historical scenarios is as follows.

[0142] Server 200's message push process, based on historical scenarios, forms a closed-loop decision-making system with a naturally connected and highly efficient workflow. When Server 200 determines that a user is in a specific historical scenario, such as a restaurant decision-making period, it triggers the message push decision process. Subsequently, Server 200 accesses the message content library and accurately matches push content strongly related to the scenario through keyword matching (such as filtering messages with tags like "food," "coupons," and "restaurant"), collaborative filtering (referencing users' historical clicks or redemption behavior in the same scenario), and real-time context fusion (combining the user's current geographical location and historical preferences, such as pushing discount information for Sichuan cuisine within business district A that matches the user's preferences). Based on this, Server 200 generates highly personalized message templates, dynamically populating them with scenario-related information, such as: "We detected that you are recently interested in Sichuan cuisine. New users of XX Sichuan restaurant in business district A are enjoying a 50% discount. You are currently only 150 meters away!" It also intelligently selects the push timing, either triggering immediately after scenario determination or choosing a time point highly relevant to the scenario (such as peak dining hours) to push the message, thereby improving user response rates.

[0143] Server 200 further optimizes itself through feedback, recording user interaction data on push notifications (such as clicks, ignores, closes, or discount redemptions) and feeding this feedback back to the scene pattern library in real time. This closed-loop mechanism enables the system to dynamically adjust scene matching rules or confidence thresholds, continuously optimize push strategies, and ensure that message accuracy improves with increased usage frequency, ultimately achieving an intelligent push experience that becomes more accurate with each use.

[0144] S500: Server 200 generates a set of personalized messages.

[0145] After receiving the personalized message from the server 200, the SDK 100 in the terminal device 300 will notify the application module (App) in plain text.

[0146] S600: Message push and visualization.

[0147] Application modules integrating SDK100 have visualization capabilities. In the Android system, calling SDK100 allows for the customization of notifications and dialog boxes, enabling notification bar alerts or in-app pop-ups to notify users of new messages received from server 200.

[0148] Preferably, SDK100 receives personalized messages sent by server 200, and then transmits plain text data to the application module via Intent, triggering BroadcastReceiver to receive callbacks, ensuring basic message delivery.

[0149] Preferably, the process of customizing notifications is as follows: call the NotificationBuilder class provided by SDK100, which supports configuring icon, title, contentText, and pendingIntent, and also supports setting notification priority and channel.

[0150] Preferably, the DialogManager class of SDK100 allows for customization of the pop-up style, supports passing in msgContent and interactive buttons, and controls the pop-up's display hierarchy through WindowManager to ensure that it is displayed first in the application foreground without obscuring the core operation area.

[0151] Server 200 employs a basic outreach + layered visualization design. Plain text ensures no messages are lost, while customized notifications and dialog boxes meet diverse interaction needs. The benefits include: First, message reach rate is improved: compared to plain text notifications, visual formats increase users' willingness to click, preventing messages from being ignored.

[0152] Second, adapt to system compatibility: through notification channels and pop-up layer control, it is compatible with all versions of Android from 6.0 to Android 14, reducing the failure of functions due to differences in system permissions or features.

[0153] Third, optimize user experience: support personalized customization to avoid the rigidity of uniform notification formats and increase user acceptance of the app.

[0154] S700: The SDK100 collects messages and scores them to determine if they match user interests. End.

[0155] SDK100 listens to the behavior of customized notifications and dialog boxes to collect user behavior information about new messages. This user behavior information includes data such as whether the user opened the message, the duration of viewing the message, and the user's interest rating of the message.

[0156] Specifically, SDK100 listens for user actions through interfaces such as setOnNotificationClickListener and setOnDialogActionListener. ① Click / view operation: Record actionTime and jumpPage; ② Browsing duration: calculated via the onPageStart and onPageEnd callbacks; ③ Rating operation: The Dialog has a built-in 1-5 star rating control. After the user selects a rating, the score and scoreRemark are recorded.

[0157] SDK100 encapsulates the above behavioral data into the UBCMsgInfo class, with core fields including: msgId, userId, actionType, actionTime, browseDuration, score, and scoreRemark, with field non-empty validation.

[0158] Using the DataReporter class in SDK100, SDK100 encapsulates the UBCMsgInfo object in JSON format and sends it to the specified interface of server 200 using the HTTPS protocol, supporting breakpoint resumption.

[0159] SDK100 is configured in this way to build a closed-loop mechanism of behavior collection, data encapsulation, security reporting, and analysis application, ensuring the integrity and accuracy of user operation data and sending it to server 200 in real time.

[0160] During the behavior collection phase, SDK100 dynamically captures user interaction behavior; during the data encapsulation phase, standardized protocols (such as Protobuf) are used to perform structured serialization processing of the data; during the security reporting phase, HTTPS encrypted transmission is used and a breakpoint resume mechanism is integrated to meet data security compliance requirements such as GDPR and avoid data loss due to network fluctuations; during the analysis and application phase, the server uses msgId to associate message content with user behavior, accurately calculates click-through rate (number of opened messages / total number of recommendations × 100%), average browsing time, and rating distribution (based on a 0.4 / 0.7 threshold system), and achieves quantitative evaluation of recommendation effectiveness; at the same time, the preference model built based on user behavior sequences supports a personalized dynamic recommendation strategy, significantly reducing the proportion of invalid pushes; in addition, user feedback collected through the scoreRemark field is directly used for product iteration and optimization, forming a closed-loop feedback system from data collection to strategy tuning.

[0161] The steps for SDK100 to collect user ratings for messages include: Different user behaviors are assigned different weights, and the weights are calculated by weighting the user behavior information. The score is calculated as follows: Score = Message opening behavior weight × A + Message browsing duration weight × B + User active interaction behavior weight × C; A, B, and C are weighting coefficients.

[0162] For example, the final score = message opening behavior weight × 0.5 + message browsing time weight × 0.3 + user active interaction behavior weight × 0.2.

[0163] Preferably, the message opening behavior weight is determined based on whether the user opened the message (1 for opening, 0 for not opening). The message browsing time weight is obtained by normalizing the ratio of the user's browsing time to the average browsing time of this type of message. The user's active interaction behavior weight is determined based on the user's interaction with the message, such as liking or commenting (1 for interaction, 0 for no interaction).

[0164] The message opening behavior weight, message browsing duration weight, and user active interaction behavior weight are encapsulated in the UBCMsgInfo class and then sent to the server in JSON format.

[0165] Server 200 uses this feedback data to determine whether the user is interested in the message, thereby evaluating the quality of the recommendation. Server 200 also conducts an overall evaluation of the information recommendation effect from multiple dimensions.

[0166] Preferably, the overall evaluation includes multiple dimensions such as click-through rate, average message rating, and interaction rate; the higher the click-through rate, average message rating, and interaction rate, the better the recommendation effect.

[0167] Preferably, the interest level of a single message is determined based on a final rating threshold: when the rating is ≥0.7, it is considered highly interested; when the rating is 0.4≤rating<0.7, it is considered moderately interested; and when the rating is <0.4, it is considered uninterested.

[0168] Regarding the click-through rate (CTR) metric, Server 200 calculates the percentage of all recommended messages that were opened by users, which is calculated as (number of opened messages / total number of recommended messages) × 100%. A higher CTR indicates that the recommended messages are more attractive overall.

[0169] Regarding the average rating dimension, server 200 calculates the final average rating of all recommended messages. The higher the average rating, the better the recommendation quality.

[0170] Regarding the interaction rate dimension, Server 200 counts the proportion of messages with active user interaction (likes, comments, etc.) out of the total number of recommended messages, which is (number of messages with interaction / total number of recommended messages) × 100%. The higher the interaction rate, the more the recommended messages can stimulate user participation.

[0171] Preferably, Figure 5 The diagram illustrates the interaction between the system of the present invention and a third party, and also shows the functional module architecture and data processing flow diagram within the message push system. Figure 5 The arrows clearly indicate the data flow between modules.

[0172] like Figure 5As shown, requests for third-party access are received by the business module. A third-party access request refers to a data interaction request initiated by a system (such as an application, website, or service) to a third-party service (such as a payment platform, map API, social platform, etc.) for the purpose of obtaining or sending specific data. The business module interacts with the analysis module (equivalent to SDK100) to exchange events and information. The analysis module reads and writes data from the message storage module and delivers newly generated messages to the message queue. The connection module connects to the terminal device 300.

[0173] The connection module retrieves messages from the message queue and sends them to the Android device through various Broker instances (such as Broker 1, Broker 2, ..., Broker n).

[0174] Specifically, the business module serves as the entry point for the system of this invention to interact with external business parties, and is used to receive third-party business requests or events.

[0175] The analysis module contains three sub-modules. For example... Figure 5 As shown, the three sub-modules are the data acquisition module, the message management module, and the message push module.

[0176] The data acquisition module collects scenario and user behavior information related to messages. The message management module handles message generation, logical judgment, and lifecycle management. The message push module sends the message queue to be sent to the connection module according to the push strategy. The message queue serves as an asynchronous processing buffer, temporarily storing new messages to decouple the analysis module and the connection module, ensuring system stability under high concurrency.

[0177] The analysis module also integrates a message storage module. This module uses a database to persistently store message content and related data.

[0178] The connection module (equivalent to a push server) is used to establish and manage long-lived connections with terminal devices (such as connecting to Android devices). The connection module internally contains multiple Broker instances (Broker 1, Broker 2, …, Brokern) to support horizontal scaling and high availability. One of the Brokers is marked as Busy, indicating that the instance is currently in a busy processing state.

[0179] It should be noted that the specific embodiments described above are exemplary. Those skilled in the art can devise various solutions inspired by the disclosure of this invention, and these solutions all fall within the scope of this invention and its protection. Those skilled in the art should understand that this specification and its accompanying drawings are illustrative and not intended to limit the scope of the claims. The scope of protection of this invention is defined by the claims and their equivalents. This specification contains multiple inventive concepts; terms such as "preferredly," "according to a preferred embodiment," or "optionally" indicate that the corresponding paragraph discloses an independent concept. The applicant reserves the right to file divisional applications based on each inventive concept.

Claims

1. A message push system based on mobile internet user behavior analysis, characterized in that, The system includes: SDK (100) is embedded in terminal device (300). When a user enters a specific area, SDK (100) collects scene information and user behavior information, and collects the user's rating of the message. The server (200) determines whether to trigger a preset geofence based on the geographical location information of the terminal device (300) and determines whether the user enters a specific area; when the user enters a specific area, it filters and forms a set of messages to be pushed based on the scene information and user behavior information; and sends the message with the highest score in the set of messages to be pushed to the terminal device (300) so as to form a visualization process through the SDK (100).

2. The system according to claim 1, characterized in that, The steps by which the server (200) determines whether a user has entered a specific area include: The geographical location of the terminal device (300) is compared with the preset geofence, and the spherical straight-line distance between the geographical location of the terminal device (300) and the center point of the geofence is calculated based on the Haversine spherical formula. The spherical straight-line distance is compared with the preset fence radius, and the user's behavior status in a specific area is determined based on the three-level state determination rule; The behavioral states include entering, being in, and leaving the specific area.

3. The system according to claim 1 or 2, characterized in that, The three-level status determination rules for the server (200) to determine whether a user has entered a specific area include: Set the step size threshold Δd, set the fence radius to R, and set the spherical straight-line distance between the geographic location and the center point of the geographic fence to d; Within the geofence area: When d≤R-Δd, the current geographical location is determined to be within the core area inside the geofence, triggering services within the specific area; Entering the fenced area: When R-Δd<d≤R+Δd, it is determined that the current location is in the transition area of ​​the geofence boundary. The server (200) starts continuous positioning sampling. If the continuous sampling results all satisfy d≤R+Δd, it is confirmed that the area has been entered and the area entry event is triggered. Leaving the fenced area: When d > R + Δd, it is determined that the current location is outside the geofence. If the previous determination state was within or within the fenced area, then the area leaving event is triggered.

4. The system according to any one of claims 1 to 3, characterized in that, The step of the server (200) filtering and forming a set of messages to be pushed based on the scene information and user behavior information includes: When the terminal device (300) enters the preset geofence area, the SDK (100) collects multi-dimensional information of the user and the terminal device (300) and sends it to the server (200). The server (200) calculates the score of each message based on user profile, scene information, user behavior information and filtering algorithm, selects information that the user is interested in based on preset threshold, and forms a set of messages to be pushed to the user.

5. The system according to any one of claims 1 to 4, characterized in that, The steps for the SDK (100) to collect user ratings for messages include: Different weights are assigned to different user behaviors, and the weights are calculated by weighting based on user behavior information; The score is calculated as follows: Score = Message opening behavior weight × A + Message browsing duration weight × B + User active interaction behavior weight × C; where A, B, and C are weighting coefficients.

6. The system according to any one of claims 1 to 5, characterized in that, The server (200) also performs an overall evaluation of the recommendation effect of the information from multiple dimensions; The overall evaluation includes multiple dimensions such as click-through rate, average message rating, and interaction rate. The higher the click-through rate, the average rating of the message, and the interaction rate, the better the recommendation effect.

7. The system according to any one of claims 1 to 6, characterized in that, The communication connection method between the SDK (100) and the server (200) includes: The SDK (100) generates a unique identifier (CID) that identifies the terminal device (300); The SDK (100) establishes a bidirectional channel with the server (200) to send the scene information and user behavior information it collects, and to receive personalized messages pushed to it.

8. A message push method based on mobile internet user behavior analysis, characterized in that, The method includes: When a user enters a specific area, the SDK (100) collects scene information and user behavior information and sends it to the server (200). The server (200) determines whether to trigger a preset geofence based on the geographical location information of the terminal device (300) and determines whether the user has entered a specific area; when the user enters a specific area, the server (200) filters and forms a set of messages to be pushed based on the scene information and user behavior information; the server (200) sends the message with the highest score in the set of messages to be pushed to the terminal device (300) so as to form a visualization process through the SDK (100).

9. The method according to claim 8, characterized in that, The steps for determining whether a user has entered a specific area include: The geographical location of the terminal device (300) is compared with the preset geofence, and the spherical straight-line distance between the geographical location of the terminal device (300) and the center point of the geofence is calculated based on the Haversine spherical formula. The spherical straight-line distance is compared with the preset fence radius, and the user's behavior status in a specific area is determined based on the three-level state determination rule; The behavioral states include entering, being in, and leaving the specific area.

10. The method according to claim 8 or 9, characterized in that, The three-level status determination rule for determining whether a user has entered a specific area includes: Set the step size threshold Δd, set the fence radius to R, and set the spherical straight-line distance between the geographic location and the center point of the geographic fence to d; Within the geofence area: When d≤R-Δd, the current geographical location is determined to be within the core area inside the geofence, triggering services within the specific area; Entering the fenced area: When R-Δd<d≤R+Δd, it is determined that the current location is in the transition area of ​​the geofence boundary. The server (200) starts continuous positioning sampling. If the continuous sampling results all satisfy d≤R+Δd, it is confirmed that the area has been entered and the area entry event is triggered. Leaving the fenced area: When d > R + Δd, it is determined that the current location is outside the geofence. If the previous determination state was within or within the fenced area, then the area leaving event is triggered.

Images