HK1259097B - Information push method, device and equipment - Google Patents

Description

Information push method, device and equipment

Technical Field

The present application relates to the field of computer technology, and in particular to an information push method, device, and equipment.

Background Art

With the development and popularization of information technology, service providers can proactively push corresponding service information to users so that users can learn about corresponding service products/services.

Currently, when service providers push service information to users, they typically implement fatigue control for the service information they push. Specifically, within a specified time period, service providers push service information to the same user less than a preset number of times to reduce the user's fatigue from receiving service information. In the prior art, service providers typically implement fatigue control based on the number of pushes to users over a recent period.

Based on existing technology, a more effective way of pushing information is needed.

Summary of the Invention

The embodiments of this specification provide an information push method, apparatus, and device to provide a fatigue control solution for pushing business information more effectively.

The embodiments of this specification adopt the following technical solutions:

The present invention provides an information push method, including:

Determine the user location corresponding to the user and the historical push records for the user;

Determining, based on the user location, a regional push control condition corresponding to the user location;

Push service information to the user according to the regional push control condition and the historical push record.

Correspondingly, the embodiment of this specification further provides an information push device, including:

A basic information determination module determines the user location corresponding to the user and the historical push records for the user;

A control condition determination module, which determines, based on the user location, a push control condition for the region corresponding to the user location;

The push processing module pushes business information to the user according to the regional push control conditions and the historical push records.

Correspondingly, the embodiment of this specification further provides an information push device, including: a processor and a memory, wherein:

The memory stores an information push program;

The processor calls the information push program stored in the memory and executes:

Determine the user location corresponding to the user and the historical push records for the user;

Determining, based on the user location, a regional push control condition corresponding to the user location;

Push service information to the user according to the regional push control condition and the historical push record.

At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:

For users who require business information push notifications, their region can be determined based on their location, and the corresponding regional push control conditions can be further determined. Regional push control conditions reflect the conditions that must be met for business information to be pushed in that region. Combined with the user's own historical push history, this allows for more multi-dimensional push control of the business information that needs to be pushed to the user.

By adopting the above-mentioned information push, fatigue control of the business information pushed to users whose locations have changed can be more effectively performed, thereby improving the business experience of users.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 is a schematic diagram of an actual application architecture based on the information push method provided in an embodiment of this specification;

FIG2 is a schematic diagram of the information push process provided in an embodiment of this specification;

FIG3 is a schematic diagram of an information push process in an actual application example provided by an embodiment of this specification;

FIG4 is a schematic diagram of a push determination process provided by an embodiment of this specification;

FIG5 is a schematic diagram of the structure of an information push device provided in an embodiment of this specification.

DETAILED DESCRIPTION

To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

In actual business scenarios, receiving service information pushed by service providers too frequently may affect the user experience. Therefore, service providers typically implement fatigue control for the service information they push to users (i.e., controlling the number of times service information is pushed within a specified period of time). Current fatigue control is typically based on the number of service information pushed in the recent past, achieving fatigue control for the service information currently being pushed.

However, some users may move between regions. For example, a user traveling abroad may change their country, or a user on a business trip may change their city. Different regions often have different business information to push, which increases the complexity of managing fatigue in pushing business information. Currently, simply using the push frequency of business messages is no longer sufficient to meet actual business needs.

To this end, an information push method is provided in an embodiment of this specification, which is used to combine the push control rules at the geographical level in the process of fatigue control of business information to achieve multi-dimensional management and control of the business information to be pushed, which can meet the current more complex business conditions and is conducive to improving the user's business experience.

It should be noted that in one or more embodiments of this specification, the business information may include promotional information related to business services or products, such as bank card application discount information, membership card discount information, coupon information, online/offline event promotion information, or movie promotion information, which are not listed here. It should also be understood that the above-mentioned business information may be sent in the form of, but not limited to, short message service (SMS), multimedia message (MMS), application notification, or system message. This should not constitute a limitation on this application.

FIG1 is a schematic diagram of the architecture on which the service push method in the embodiments of this specification is based.

In Figure 1, the service server is configured with corresponding service information fatigue control rules (hereinafter referred to as push control conditions), particularly push control conditions for different geographical levels. Generally speaking, the service server can control the fatigue of service information pushed to users based on the user's location and the push control conditions at the corresponding geographical level.

Generally speaking, a service server is a server behind the scenes of a service provider. Service providers here include, but are not limited to, businesses such as stores, hotels, restaurants, cafes, gas stations, and cinemas, as well as service providers such as telecommunications operators and websites. In some embodiments described herein, a service server may also be a server on a service platform. In other words, the services of various service providers are aggregated on the service platform, allowing users to access services provided by different service providers through this service platform.

The above-mentioned business server may adopt a single server, a clustered server or a distributed server architecture, which is not specifically limited here.

The user in Figure 1 can receive service messages pushed by the service server through their terminal. These terminals include, but are not limited to, smartphones, smartwatches, tablets, and smart wearable devices. Furthermore, the user's terminal typically includes location-based services (LBS), allowing the service server to learn the user's location through the terminal.

Based on the architecture described in FIG1 , the technical solutions provided in the embodiments of this specification will be described in detail below.

The embodiment of this specification provides a service push method, as shown in FIG2 , which specifically includes the following steps:

Step S201: Determine the user's location and historical push records for the user.

In the embodiments of this specification, the acquisition and determination of the user's location can be achieved through the LBS of the terminal used by the user, which will not be described in detail here.

The historical push record for a user can be considered as a record of the service information pushed to the user before the current moment. As a feasible way in the embodiment of this specification, the historical push record can include content such as "user ID + push record + push time".

The user identifier can usually be the user's account/ID. In actual application scenarios, the user's account/ID is usually bound to the terminal device used by the user. In this way, after determining the location of the terminal used by the user (indicating the user's location) through the above-mentioned LBS, the user's account/ID can be further determined based on the terminal's MAC address, device number and other information, combined with the pre-established binding relationship (the binding relationship between the user identifier and the terminal). Therefore, the user's historical push records can be determined based on the user's account/ID.

Of course, the above process should not constitute a limitation to this application.

Step S203: Determine the regional push control condition corresponding to the user location according to the user location.

In the embodiments of this specification, different regional push control conditions are set for different geographical regions. Specifically, the regional push control conditions described here primarily control the number of push notifications within a set time period for a particular region. For example, for region A, the number of service information push notifications to users within three days may not exceed two.

Generally speaking, different regions can set different regional push control conditions, which can be set according to the business needs of the region, and this should not constitute a limitation of this application. Of course, setting unified regional push control conditions for multiple regions should also be included in the scope of this application.

Step S205: Pushing service information to the user according to the regional push control condition and the historical push record.

After determining the regional push control conditions for the current region and the user's own historical push records, the service server can determine whether the user is in the current region and can push the corresponding service information to the user. This shows that the control conditions for service information push are no longer limited to push frequency, but can also be controlled based on the user's region.

Through the above steps, for users who need business information push, the user's region can be determined based on the user's location, and the corresponding regional push control conditions can be further determined. The regional push control conditions reflect the conditions that must be met for business information push in that region. Then, combined with the user's own historical push records, more multi-dimensional push control can be implemented for the business information that needs to be pushed to the user.

By adopting the above-mentioned information push, fatigue control of the business information pushed to users whose locations have changed can be more effectively performed, thereby improving the business experience of users.

For the above method, its execution subject can be a service server or a telecom operator's information push device (not shown in the architecture of FIG1 . It is understandable that the telecom operator's information push device is usually used to push service information to users via SMS/MMS, etc.). In addition, during the execution of the above steps, the execution subject can change. For example, the service server can execute the above steps S201 and S203, and then the telecom operator's information push device can execute the above step S205. Of course, the specific implementation will be determined according to the needs of the actual application and does not constitute a limitation of this application.

Regarding the above method, it should be noted that in actual application scenarios, the corresponding regions can be divided according to different geographical levels. The geographical levels mentioned here can be considered to be geographically divided according to countries, provinces/states, cities, business districts, etc. Then, the different regions obtained based on the geographical level can be, for example: XX country, XX province/state, XX city, XX business district, etc. Of course, the division of regions at different geographical levels is usually based on business needs.

Furthermore, corresponding regional push control conditions may be set for the above-mentioned different regions. In other words, in the aforementioned method, the process of determining the regional push control conditions corresponding to the user location based on the user location may specifically include: determining the region to which the user location belongs, and determining the regional push control conditions pre-set for the region as the regional push control conditions corresponding to the user location.

As previously mentioned, in the embodiments of this specification, regional push control conditions primarily refer to the number of service information pushes within a specified time period, set for that region. Therefore, pre-setting regional push control conditions for a region may specifically include: setting a control time period for any region, and setting a push count threshold within that control time period; the push count threshold set within that control time period is then determined as the regional push control condition for that region.

As one method in the embodiments of this specification, a unified regional push control condition can be set for different regions that have a geographical relationship. For example:

Region 1: China; Region 2: Zhejiang Province; Region 3: Hangzhou

The three regions mentioned above are geographically related. Assume that the regional push control condition set for these three regions is "push once every three days." Then, assuming user A is located in Hangzhou, when pushing business information to user A, the three aforementioned regional push control conditions must be met. Specifically, the specific execution process in this example is shown in Figure 3 and includes the following steps:

Step S301: Obtain historical push records of user A.

Step S303: Based on the historical push records of user A, determine whether the number of times the business information is pushed to user A in China within 3 days is greater than or equal to 1 time. If so, execute step S303; otherwise, execute step S305.

Step S305: Based on the historical push records of user A, determine whether the number of times business information is pushed to user A in Zhejiang Province within 3 days is greater than or equal to 1 time. If so, execute step S303; otherwise, execute step S307.

Step S307: Based on the historical push records of user A, determine whether the number of times business information is pushed to user A in Hangzhou within 3 days is greater than or equal to 1 time. If so, execute step S303; otherwise, execute step S309.

Step S309: Push business information to user A.

Of course, as another method in the embodiments of this specification, different regions with affiliation at the geographical level can set different regional push control conditions. Still using the regions in the above example, then, according to the geographical hierarchical relationship, the regional push control conditions can be:

The push control conditions for China are: push once every 5 days;

The push control conditions in Zhejiang Province are: push once every three days;

The push control conditions in Hangzhou are: push once every two days.

Based on the above regional push control conditions, the actual execution is similar to the process shown in Figure 3, and will not be elaborated here.

Of course, the above two examples are only for more intuitively illustrating the actual execution process of the information push method in this application. The setting of regional push control conditions is not limited to this, and can be determined according to the needs of actual application. This should not constitute a limitation on this application.

In addition, in addition to setting corresponding regional push control conditions for different regions, corresponding control conditions can also be set for the business content that needs to be pushed. That is, for the same business content, the frequency or number of times it is pushed to the user can be controlled. Generally speaking, the control conditions for business content are applicable to different regions, so in some embodiments of this specification, the control conditions for business content can be regarded as regional push control conditions for each region. That is, setting regional push control conditions for regions in advance may specifically include: setting a control duration for each type of business content, and setting a push count threshold within the control duration, and determining the push count threshold set for each type of business content within the control duration as the regional push control condition corresponding to each region. This does not constitute a limitation of the present application.

Therefore, it is possible to decide whether to push corresponding business information to the user according to the above push control conditions. That is, according to the regional push control conditions and the historical push records, the business information is pushed to the user, as shown in FIG4 , including the following steps:

Step S401: Determine the region to which the user is located and the service content to be pushed.

Step S403: Based on the region to which the user is located and the service content to be pushed, determine whether the historical service information pushed to the user within the specified time period exceeds the set push count threshold; if so, execute step S405; otherwise, execute step S407.

Step S405: Do not push service information to the user.

Step S407: Pushing business information to the user.

In a feasible embodiment of the present specification, after pushing service information to the user, the service server will also record it in order to reset the aforementioned regional push control conditions. Specifically, the structure of the record can be in the following form:

User ID + region ID + push time, or user ID + content ID + push time

As mentioned above, the user identifier may be a user account/ID, etc.

The region identifier can be the name, number or abbreviation of the region, such as: China (CN), Zhejiang Province (Zhe), Hangzhou City (HZ). Of course, the region identifier may adopt other coding forms, which should not be used as a limitation to this application.

The content identifier is usually an identifier of the service content, and may specifically include a service type number, a service serial number, a service/product name, a service provider name, or a combination thereof.

For example: Continuing with the previous example, assume that the corresponding business server pushes some business information to user A at 10:01 on February 1, 2018. When the business information is pushed, user A is located in Hangzhou. Then, the push record generated by the business server can be:

UserA (user ID)-HZ (region ID)-20180201-10:01 (push time)

It is worth noting that since the region "Hangzhou City" belongs to the region "Zhejiang Province", which in turn belongs to the region "China", if the push control conditions for Hangzhou City are reset, the push control conditions for Zhejiang Province and China will also be reset accordingly. In other words, the business server will also generate the following push records:

UserA-浙-20180201-10:01, and UserA-CN-20180201-10:01.

Moreover, after recording, the service server can reset the above-mentioned regional push control conditions. In other words, the above-mentioned regional push control conditions can be re-timed at the moment of -10:01 on February 1, 2018.

As can be seen from the above, fatigue control can be achieved by setting push control conditions at different geographic levels by dividing the regions. These push control conditions at different geographic levels do not affect each other. Furthermore, the stored push records are more diverse, typically generated and stored as multiple records based on different geographic levels. Even if a record is lost or invalid, the other records can still be used as a reference.

The above is the information push method provided by the embodiment of this specification. Based on the same idea, the embodiment of this specification also provides a corresponding information push device.

Specifically, the information push device provided in the embodiments of this specification is shown in FIG5 , and the device includes:

Basic information determination module 501, determining the user location corresponding to the user and the historical push records for the user;

A control condition determination module 502 determines, based on the user location, a regional push control condition corresponding to the user location;

The push processing module 503 pushes service information to the user according to the regional push control condition and the historical push record.

Furthermore, the basic information determination module 501 determines the location of the terminal used by the user through location-based services as the user location, and determines the historical push records of the user in the stored historical push records according to the user identifier pre-bound to the terminal.

Furthermore, the control condition determination module 502 determines the region to which the user location belongs, and determines the region push control condition pre-set for the region as the region push control condition corresponding to the user location.

Furthermore, the control condition determination module 502 sets a control duration for any region, and sets a push count threshold within the control duration, and determines the push count threshold set within the control duration as the regional push control condition corresponding to the region.

Furthermore, the control condition determination module 502 sets a control duration for each type of business content, and sets a push count threshold within the control duration, and determines the push count threshold set for each type of business content within the control duration as the regional push control condition corresponding to each region.

Furthermore, the push processing module 503 determines whether the historical business information pushed to the user within the specified time period exceeds the set push count threshold based on the region to which the user is located and the business content to be pushed. If so, the business information will not be pushed to the user; otherwise, the business information will be pushed to the user.

The apparatus further includes a record generating module 504 for determining the user ID, region ID, and push time of the user, and generating a push record according to the user ID, region ID, and push time.

The apparatus further includes 505: a condition resetting module, configured to reset the regional push control condition.

Based on the device shown in FIG5 , in actual application, it can be implemented by a physical device (such as a terminal device). Specifically, the device includes a processor and a memory, wherein:

The memory stores an information push program;

The processor calls the information push program stored in the memory and executes:

Determine the user location corresponding to the user and the historical push records for the user;

Determining, based on the user location, a regional push control condition corresponding to the user location;

Push service information to the user according to the regional push control condition and the historical push record.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the device, equipment, and media embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For relevant parts, refer to the descriptions of the method embodiments and will not be repeated here.

Thus far, specific embodiments of the present subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing may be advantageous.

In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present invention is described with reference to the flowcharts and/or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of processes and/or boxes in the flowchart and/or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims (17)

1. An information push method, comprising: Determine the user's location and the user's historical push notification records; Based on the user's location, different push control conditions are determined for different regions at different geographical levels corresponding to the user's location. The different regions at different geographical levels are different regions that have a relationship at the geographical level. Based on the regional push control conditions corresponding to different regions at different geographical levels and the historical push records, service information is pushed to the user, including: In order of geographical hierarchy, it is determined whether the historical push records meet the push control conditions corresponding to different regions at different geographical levels. If none of the historical push records meet the push control conditions for each region, then business information is pushed to the user. 2. The method as described in claim 1, wherein determining the user's location and historical push records for the user specifically includes: The location of the user's device is determined based on location services and used as the user's location. Based on the user identifier pre-bound to the terminal, the user's historical push records are determined from the stored historical push records. 3. The method as described in claim 1, wherein determining the regional push control conditions corresponding to the user's location based on the user's location specifically includes: Determine the region to which the user's location belongs; The pre-set region push control conditions for the region are determined as the region push control conditions corresponding to the user's location. 4. The method as described in claim 3, wherein pre-setting regional push control conditions for a specific region includes: For any given region, a control duration is set, and a threshold for the number of push notifications is set within that control duration. The threshold number of push notifications set within the control duration will be determined as the regional push control condition for the region. 5. The method as described in claim 3, wherein pre-setting regional push control conditions for a specific region includes: For each type of business content, a control duration is set, and a threshold for the number of pushes is set within the control duration; The threshold number of pushes for each type of business content within the control period is determined as the corresponding regional push control condition for each region. 6. The method as described in claim 4 or 5, wherein service information is pushed to the user based on the regional push control conditions and the historical push records, specifically including: Based on the user's location and the required push content, determine whether the historical business information pushed to the user within a specified time period exceeds the set push frequency threshold. If so, then no business information will be pushed to the user; Otherwise, business information is pushed to the user. 7. The method of claim 1, further comprising: Determine the user's user ID, region ID, and push time; A push record is generated based on the user identifier, region identifier, and push time. 8. The method of claim 6, further comprising: Reset the push control conditions for the region. 9. An information push device, comprising: The basic information determination module determines the user's location and the user's historical push records. The control condition determination module determines, based on the user's location, the push control conditions corresponding to different regions at different geographical levels corresponding to the user's location. The regions at different geographical levels are different regions that have a relationship at the geographical level. The push processing module pushes service information to the user based on the regional push control conditions corresponding to different regions at different geographical levels and the historical push records, including: In order of geographical hierarchy, it is determined whether the historical push records meet the push control conditions corresponding to different regions at different geographical levels. If none of the historical push records meet the push control conditions for each region, then business information is pushed to the user. 10. The apparatus of claim 9, wherein the basic information determination module determines the location of the terminal used by the user based on location services as the user location, and determines the user's historical push records in the stored historical push records according to the user identifier pre-bound to the terminal. 11. The apparatus of claim 9, wherein the control condition determination module determines the region to which the user's location belongs, and determines the region push control conditions pre-set for the region as the region push control conditions corresponding to the user's location. 12. The apparatus of claim 11, wherein the control condition determination module sets a control duration for any region, sets a push count threshold within the control duration, and determines the push count threshold set within the control duration as the region push control condition corresponding to the region. 13. The apparatus of claim 11, wherein the control condition determination module sets a control duration for each type of service content, and sets a push count threshold within the control duration, and determines the push count threshold set for each type of service content within the control duration as the corresponding regional push control condition for each region. 14. The apparatus of claim 12 or 13, wherein the push processing module, based on the region to which the user's location belongs and the service content to be pushed, determines whether the historical service information pushed to the user within a specified time period exceeds a set push count threshold; if so, it does not push service information to the user; otherwise, it pushes service information to the user. 15. The apparatus of claim 9, further comprising: a record generation module, which determines the user's user identifier, region identifier, and push time, and generates a push record based on the user identifier, region identifier, and push time. 16. The apparatus of claim 9, further comprising: a condition reset module for resetting the region push control conditions. 17. An information push device, comprising: a processor and a memory, wherein: The memory stores the information push program; The processor calls the information push sequence stored in the memory and executes it: Determine the user's location and the user's historical push notification records; Based on the user's location, different push control conditions are determined for different regions at different geographical levels corresponding to the user's location. The regions at different geographical levels are different regions that have a relationship at the geographical level. Based on the regional push control conditions corresponding to different regions at different geographical levels and the historical push records, service information is pushed to the user, including: In order of geographical hierarchy, it is determined whether the historical push records meet the push control conditions corresponding to different regions at different geographical levels. If none of the historical push records meet the push control conditions for each region, then business information is pushed to the user.