PROMOTION CODE VALIDATION APPARATUS AND METHOD

Information

  • Patent Application
  • 20190147474
  • Publication Number
    20190147474
  • Date Filed
    January 10, 2019
    5 years ago
  • Date Published
    May 16, 2019
    5 years ago
Abstract
A method including interacting with a promotion code provider programmatically, providing a promotion code to a validation function of the promotion code provider, and evaluating a response from the promotion code provider. The act of interacting with a promotion code provider can include controlling an interface that simulates user actions, such as but not limited to controlling an in-memory web browser through an API, where the API provides a set of functions for simulating user actions. Accordingly, the method can be used to quickly and easily determine whether one or more promotion codes, such as online coupons, are valid.
Description
FIELD OF THE INVENTION

This invention relates generally to the field of online shopping and customer discounts, such as through the use of promotion codes.


BACKGROUND

Today, internet shoppers have no way of knowing if an online coupon code or promotion code is valid. There are, for instance, various coupons, discount numbers, promotion codes, and the like that online shoppers can enter in a website to attempt to receive a discount when making an online purchase. These coupons, discount numbers, or promotion codes will generally be referred to as “promotion codes.” Typically, shoppers have to test the validity of promotion codes at checkout to see if a retailer will accept them. Reasons for a retailer not accepting a promotion code include, but are not limited to, the following:


(1) the promotion code has expired (its applicable date has passed);


(2) the promotion code cannot be applied to the current shopping basket (e.g. price of items in basket is insufficient for the discount, promotion code applies to a different product than that selected in basket);


(3) the promotion code cannot be redeemed due to the user's profile (location, etc. . . . ); or


(4) the promotion code has been deactivated by retailer.


The typical way to validate a promotion code, therefore, involves the manual validation of the promotion code by the online shopper during the shopping process. This requires every internet shopper to perform the following steps:


(1) visit the retailer they want to make a purchase from;


(2) add one of the products they want to buy to the shopping cart;


(3) get to the checkout page;


(4) open a new browser tab, and find a promotion code for that retailer;


(5) go back to the retailer's website and apply the promotion code to test whether it is valid; and


(6) repeat from step 4, until the online shopper purchases the item after finding (or not finding) a promotion code he/she is satisfied with or does not make a purchase and abandons the shopping cart.


Put simply, online shoppers have no way of knowing a promotion code's validity without painstakingly performing the manual steps outline above.


SUMMARY OF INVENTION

According to one embodiment, a method of the invention includes interacting with a promotion code provider programmatically, providing a promotion code to a validation function of the promotion code provider, and evaluating a response from the promotion code provider. The act of interacting with a promotion code provider can include, for example, controlling an interface that simulates user actions, such as but not limited to controlling an in-memory web browser through an API, where the API provides a set of functions for simulating user actions. The act of interacting with a promotion code provider can include navigating to a website of the promotion code provider to a location where a promotion code can be tested. Further, the step of evaluating a response from the promotion code provider can include, for example, determining whether the promotion code is valid. Accordingly, the method can be used to determine whether a promotion code, such as an online coupon, is valid.


Another embodiment of the invention is a computer-readable storage media embodying logic that is operable when executed to perform a series of steps. These steps include interacting with a promotion code provider programmatically, providing a promotion code to a validation function of the promotion code provider, and evaluating a response from the promotion code provider.


Yet another embodiment of the invention is an apparatus that includes at least one driver module, wherein the driver module is operable to control an interface that simulates user actions. The apparatus also includes a monitor to manage the at least one driver. In addition, the driver module contains logic that is operable when executed to: (a) provide a promotion code to a validation function of the promotion code provider and (b) evaluate a response from the promotion code provider. In use, the apparatus can be used to determine whether a promotion code, such as an online coupon, is valid.





BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated in the figures of the accompanying drawings which are meant to be exemplary and not limiting, in which like references are intended to refer to like or corresponding part, and in which:



FIG. 1 is a flow diagram of a method that can be used to validate one or more promotion codes according to a preferred embodiment of the disclosed subject matter;



FIG. 2 is a block diagram showing the environment for use of the invention in one embodiment;



FIG. 3 is a block diagram that shows greater detail of the promotion code provider 60 shown in FIG. 2;



FIG. 4 is a block diagram of one embodiment of the invention;



FIG. 5 illustrates one feature of one of the drivers 50 of FIG. 4;



FIG. 6 is a block diagram that shows greater detail of the embodiment of FIG. 4;



FIG. 7 is a block diagram that shows greater detail of the embodiment of FIG. 6;



FIG. 8 is a block diagram that shows an evaluation of paths during the navigation of a website according to one embodiment of the invention;



FIG. 9 shows the scoring of paths during the navigation of a website according to one embodiment of the invention; and



FIG. 10 is an example of what a driver 50 according to one embodiment of the invention will assemble and interpret at each page evaluation from a start node.





DETAILED DESCRIPTION

To address the need set forth above, according to one aspect, the invention includes a method and apparatus that can automatically validate one or more promotion codes. FIG. 1 is a flow chart that illustrates the operation of the invention in one embodiment. As set forth in FIG. 1, block 10 is an act of interacting with a promotion code provider programmatically. This means, for example, using a recursive process to determine where to go on a retailer's website to enter a promotion code. Programmatic interaction within this context can be the act of communicating with a promotion code provider through a particular set of instructions exposed through technology interfaces, such as software or hardware. The interaction may occur through a variety of mediums, such as a web interface, mobile interface, wire protocol, or shared data store such as a queue or similar construct. The method of interaction may occur through software or hardware, so it can be language independent, and may be initiated directly through the exposed interface or via a software development kit or bundled set of libraries. The interfaces may be provided directly by the provider, or through a third party, such as a hosting provider or software vendor. Next, at block 20, a promotion code is provided to a validation function of the promotion code provider. Finally, at block 30, the method evaluates a response from the promotion code provider. This evaluation can include, for example, determining whether the promotion code is valid. As such, this method allows for the automated validation of one or more promotion codes.


As used herein, the term “promotion code provider” can be one or both of a merchant or a source of a promotion code. The merchant, for example, could be a merchant or reseller that accepts promotion codes from third party sources. The source of a promotion code, for example, could be a third party that provides or accepts promotion codes for products and could include, for example, a product manufacturer or seller.


The present invention solves the problem of online shoppers spending time searching for and testing the validity of promotion codes. The invention can, for example, automatically test the validity of promotion codes and only deliver online shoppers promotion codes that a retailer will accept. This saves the user a significant amount of time because they no longer need to manually validate promotion codes.


The invention also solves problems for online merchants, which collectively experience high shopping cart abandonment rates, which decrease sales. Shopping cart abandonment refers to the loss of a customer who is going through the check-out process of an online transaction.


Because much of online shopping is impulse driven, there is a higher probability that the online shopper will abandon the shopping cart with every additional second that the online shopper does not make a purchase. Over half of all online shoppers use promotion codes, and the searching and testing of these promotion codes increases the time they spend going through the purchase process and thus results in higher shopping cart abandonment. The invention saves the online shopper a significant amount of time by automatically testing the validity of promotion codes, which helps to decrease the time online shoppers spend going through the purchase process, this decreasing abandonment rates.



FIG. 2 shows the environment for use of the invention in one embodiment. FIG. 2 shows, for example, a driver 50 connected to a promotion code provider 60 through an interaction channel 70 for executing instructions and passing data to the promotion code provider 60. The driver 50 can be, for example, a program that executes a series of instructions. The promotion code provider 60 can be, for example, the website for an online merchant. The promotion code provider 60 includes a validation application interface 80, which is the interface such as a website page that allows a user to enter a promotion code.



FIG. 3 shows greater detail of the promotion code provider 60 shown in FIG. 2. The promotion code provider 60 includes logic 62 to create web pages for display. FIG. 3 illustrates that the promotion code provider 60 includes put code 110, which allows the user to submit a promotion code for validation. For instance, the checkout page for many online merchants includes a user interface for entering and submitting a promotion code. The driver 50 interacts with this put code 110 programmatically to automatically validate a promotion code. The promotion code provider 60 also includes validate code 112, which is the promotion code provider's code that determines whether to accept a promotion code, whether it has expired, or whether there is some other issue with the promotion code that prevents its use. Finally, the promotion code provider 60 includes a get response function 114, which is the promotion code provider's mechanism to submit back to the driver 50 the result of whether the promotion code is valid. This get response function 114, for example, can include the provision of a message to the driver 50 that the promotion code has been accepted or that the promotion code has expired.



FIG. 4 is a block diagram of one embodiment of the invention. In this embodiment, the invention consists of two main sub-systems, a driver 50 which is capable of interacting with a merchant's website, and a monitor 120, which is responsible for controlling the work queue of promotion codes to be validated. The monitor 120 can instantiate one or more drivers 50, depending on the volume and type of promotion codes to be validated. FIG. 4, for example, illustrates three such drivers 50, although the invention can scale up or down the number of drivers 50 depending on the promotion codes to be validated.


Referring again to FIG. 4, the driver 50 can operate by controlling an in-memory web browser through an automation application programming interface (API). FIG. 6 illustrates this in more detail. In particular, the driver 50 uses an API 130 to control an in-memory process 132 including an in-memory web browser 135 than can be used for promotion code validation. The API 130 provides a set of functions through which the driver program simulates actions normally performed by an end user, such as an online shopper. The API 130 can include three main entry points: (1) the merchant discovery entry point; (2) the validation entry point; and (3) the configuration entry point. The caller can communicate with the API 130 through a REST based interface by selecting the function to execute and then specifying the merchant on which they want to execute the function against. The calling pattern, for example, can be as follows: http://api.shopply.com/{merchant}/{coupon}validate. In this calling pattern, {merchant} and {coupon} are values provided to the API 130. The API 130 can respond by passing a JSON object containing the validation data back to the caller through the response's body. The API 130 can operate in both synchronous and asynchronous mode, which is determined by the caller when they submit the request.


Referring to FIGS. 4 and 7, the monitor 120 manages one to many drivers 50. The monitor 120 is connected to a work queue 140, which represents a set of batches 142 of promotion codes to be validated against a specific merchant. The monitor 120 can be based on a throttling pattern, and it can dynamically scale the number of drivers 50 being instantiated and operated based on a service level agreement (SLA) policy. FIG. 7, for example, shows two of the drivers 50 of FIG. 6, each controlling an in-memory web browser 135. The life eycle of the monitor 120 involves checking the work queue 140 on a regular interval and establishing a count of how many promotion codes are ready for validation. The monitor 120 then examines the historical validation rate data (based on past attempts to validate promotion codes) to establish an optimal instance count by inspecting the SLA and identifying whether the current instance count multiplied by the mean time to validate per instance will meet the expected throughput for the SLA per merchant. The monitor 120 will then increase or reduce the number of instances of drivers 50 to ensure it can meet the SLA min and max performance boundaries.


Referring again to FIG. 1, the driver 50 can interact with a promotion code provider 60 programmatically. In such a manner, the driver 50 can determine where a promotion code validation page and location exists within a merchant's website. Doing so allows for the automated validation of one or more promotion codes.



FIG. 8 shows such a recursive process through which a driver programmatically interacts with a promotion code provider. FIG. 8 shows the use of a reset checkpoint 152 for resets, a checkpoint that determines whether the driver 50 needs to reset to restart the exploration, and a state of reach its goal 156—a promotion code entry page. To interact programmatically with a promotion code provider 60, each instantiated driver 50 starts at a well-known point, also known as the reset checkpoint 152. The purpose of the reset checkpoint 152 is to provide the driver 50 a known state from which to start its automation process. From the reset checkpoint 152, each driver 50 navigates the merchant website, selecting the appropriate path to its goal state 156, which is the page where a promotion code can be tested. If at any point in the process, the driver 50 does not understand its current environment, it returns to the reset checkpoint 152, and starts the exploration process.


As an example according to FIG. 8, the driver 50 will start at a known entry point, such as the root or home page of a promotion code provider 60, or root domain of the merchant, and then begin enumerating the possible exit elements of the page. As the driver 50 begins recursively exploring each exit path, it will check 154 if it is at its goal state (a page where a promotion code can be validated), or, if not, what the possible exit paths are that do not create a cyclic relationship. If, at some point, the driver 50 reaches a state where there are no exit paths, and there is no promotion code entry page, then it may determine that it is at an invalid state. The driver 50 may, for instance, determine that it is at an invalid state if it determines that some of the explorations have not completed successfully or have experienced an error. At this point, the driver 50 may restart by zeroing all recursions, going back to the start point, and restarting the exploration.


The overall exploration process is a set of Bayesian networks, where each node in the macro network is an individual page on a merchant website. Each network consists of one to many nodes with each node representing a web page on the site. The start node is the current page being explored and each outbound node represents a page destination accessible by an HTML element capable of navigation, such as an anchor or link. Over time, the driver 50 builds up a set of paths that describes a relationship between nodes where the conclusion of each path has been a successful promotion code page. When the driver 50 reaches a promotion code validation page, it takes each node in its travelled path and increments its score by the total distance travelled by the number of nodes travelled. Over time, nodes that prove to lead the driver 50 to a promotion code validation page will have the highest scores, helping the driver 50 establish a fast path to the promotion code validation page.



FIG. 9 shows one such network. FIG. 9 shows, for instance, the score from a start page 162 to a search page 164 being 0.5, the score for a page for contact information 166 as a 0.0, and the score for a checkout page 168 being 0.9. Thus, the chances are the highest that the checkout page 168 will be a page where a promotion code can be entered, the search page 164 is the next most likely page where a promotion code can be entered, and the contact us page 166 is the least likely.


The scoring is based on historical data built up over time by the system. Each evaluation involves doing a depth first traversal using a shortest path algorithm such as Dijkstra or Bellman-Ford. The performance of this approach increases after each consecutive exploration by the magnitude of changed deltas in the site map since the last exploration. Each score represents the likelihood that the algorithm will and a page where a coupon validation function exists. This score is recorded at each edge between nodes, where each node is a web page in a site being explored, and each edge is a relationship between two pages formed by an element, such as a hyperlink. The score is determined by the algorithm during its traversal process, based on a set of rules. These rules measure the divergence potential of a page. For example, a page with four hyperlinks to pages within the site domain has a higher likelihood of leading the driver to a successful state than a page with two hyperlinks that link to pages outside of the sites domain. The basic principal of the scoring function is to find convergence within site pages towards a page that provides a validation function. In the instance where the provider publishes a programmatic interface, such as an application programming interface or API, then the scoring function will rank this highest because pages that provide some form of interface receive a higher score than non-programmatic interfaces, such as web pages.


When the driver 50 starts its exploration process, it begins at a root node, such as, for example, the start page 162 of a site as shown in FIG. 9. The driver 50 then creates a set of multiple recursion paths to explore. It determines the list of exit paths, and then selects each path and explores it. At each evolution, it establishes the exit paths, and picks the first one when it reaches an end state, such as either a promotion code entry page, a page with no exit paths, or an exit path to a page it has already visited. The driver 50 then ends its traversal and recurses back to the start. At this point, the next exit path from the root is selected and traversed to the end.


Each time the driver 50 recurses and traverses to an end state, it places a score against the graph edges that led to the end state, with higher scores being given to edges that led to a promotion code validation page, lower scores being assigned to pages that led to dead ends (no exit paths), and the lowest score being given to cyclic edges. FIG. 9, for example, shows exemplary scores for three traversals from a start page 162.


As an example, if the driver 50 starts at the home page, there may be four possible ways to exit the page—-there might be 3 links and one input element. The driver 50 assembles these in a list, and then selects the first path, such as the first of the 3 links. It navigates that link and evaluates the destination. If the destination caused the driver 50 to leave the domain of the site, for example, from domainx.com to domainy.com, then the recursion terminates. If the destination is a page within the parent domain (including sub-domains), then the page is evaluated as potentially having a promotion code input box, an input control, or exit paths. If there are no exit paths and no promotion code input boxes or input controls, then the recursion terminates. If the page has exit paths, the algorithm recluses. If the destination has a promotion code control, the driver 50 records this and still exits, but does so by setting a flag to indicate success. Each root path is evaluated until a success is found or until all root paths have been explored.


Using the recursive traversal process set forth above allows the driver 50 to learn about various merchant websites and use that learning in the future. For instance, if a driver 50 has evaluated a particular merchant website in the past, the next time the driver 50 arrives at the same merchant site, it will look up the learning corpus from its path traversals, and if a prior successful path exists, it will validate this path. If the path succeeds, the driver 50 navigates it. If not, the driver will evaluate a new path in the manner set forth above.


For each node in the macro network, the invention can establish a micro network for all possible exit points. In exploring a web site and looking for a particular goal, it is important to have some basis for moving forward. Web pages have a finite set of possible exit points, because the published specification for HTML describes the possible controls that enable site navigation. Being able to determine how to move forward from a page helps the driver explore the site, making it possible to find the promotion code validation page and control. Without an exit point, it would be very difficult to understand how to discover the promotion code validation page in a methodical, efficient, programmatic manner. Each node in the micro graph represents an element on the page, where the edges represent meaningful relationships and scores.



FIG. 10 is an example of what the driver 50 will assemble and interpret at each page evaluation from a start node 172. Each node represents an element on the page, for example, an image 174 or hyperlink 176. Some elements have potential actions, for example, an Anchor, also known as a hyperlink, that can be clicked or an input 178 that can have text entered into it. The start node 172 in FIG. 10 represents the driver 50 and the nodes 174, 176, 178 to the right represent elements that provide a potential exit point. Each node also has meta information associated with it. For example, the driver 50 will look for interaction elements, like links 176 or buttons, that have a close proximity to an input element, such as a text box 178 for inserting a promotion code. If an interaction element is in close proximity to an input element, this makes it more likely to be associated in some higher level concept, like a form. The DOM is the document object model, which is the graph/tree structure that underlies all web pages and describes the structure and relation of elements that make up the page.


There are two graphs stored within the system. The graphs can be stored either as adjacency matrices or lists, depending on the size of the site. The primary basis for the graphs is to describe relationships between web pages, or within a web page, relationships between elements. The data structure is laid out to provide efficient application of the search algorithm, where the union of two nodes provides information on scoring, proximity, etc. First, the site-level graph lays out the relationship between Web pages. For example, the home page links to the contact page. Second, the page-level graph shows the relationship of elements on the page. For example, on the home page, there are two hyperlinks and two images. Like the site-level graph, the page-level graphs are scored using historical metrics based on prior explorations, but are also weighed on change. The page DOM can be calculated based on elements, but not necessarily based on layout. Any change in the DOM score will require the page to be explored again.


Each element on the page is assessed on two attributes. The first attribute is its exit-ability, which is based on a finite set of known HTML elements. The second attribute is proximity to an exit-able element. The edges on the graph are based on actions, with implicit decision criteria, based on a forward-flow model where the system is always moving forward.


The primary benefit of using a combination of machine learning, graph theory, and automation, as explained above, is that any website that offers a user the ability to validate a promotion code can be explored by the system. Machine learning can help to optimize this process to run at scale, especially in relation to using learned routes and just-in-time evaluation of page changes. Graph theory can allow the system to simulate multiple explorations using a dynamic set of traversal and scoring algorithms, such as Dijkstra, Bellman-Ford, and a range of models such as generalized Voronoi graphs or frontier-based methods.


Referring again to FIG. 1, the system according to the invention provides a promotion code 20 to a validation function of the promotion code provider. After a promotion code entry page has been found, for example, according to the technique set forth above, promotion codes can be entered on the web page by the driver using an automation API. When a promotion code entry box is discovered, the driver 50 will set the text of the element to a promotion code, and the submit function of the page is invoked to execute the validation function of the web page. As such, the driver 50 is automated to enter promotion codes on the appropriate page and location of a merchant's website. The driver 50 works from a list of codes to validate, and during each navigation evolution, determines the appropriate workflow for each code. Some codes will require a re-run of the evolution. For example, if the code is only applicable for a specific product, the driver 50 will need to restart the evolution, using the required product as part of the exploration. The overall system in which the driver operates continuously collects information that is evaluated for further runs. Some codes will be batched together, some will be validated individually, with specific environment settings and test data. The driver 50 can, for example, cycle through a plurality of promotion codes in the queue. For each promotion code, the driver 50 can enter the particular promotion code in the input box and then submit the promotion code to the promotion code provider. Some promotion code providers may require additional text or inputs in order for a promotion code to be validated. For instance, an online merchant's website may require the selection of a product for purchase or the clicking of a check box to indicate agreement with certain terms.


Referring again to FIG. 1, the system according to the invention evaluates a response 30 from the promotion code provider 60. For example, after receiving a response from the website, the driver 50 compares the pre-send state to the post-send state and looks for any new or changed elements that have keywords associated with validation responses. Any elements are captured as a response and are then analyzed to determine the end status of the evaluation. The possible response results vary across online merchants and are dependent on the promotion code rules implemented by such merchants. A typical result can be “The promotional code you entered is not valid” or “The promotional code you entered has expired.” To evaluate the validity of a promotion code, the driver 50 uses a set of known words within the response result. For example, a response result that includes the word “expired” may be deemed to indicate an expired promotion code.



FIG. 5 illustrates one feature of one of the drivers 50 of FIG. 4, also known as validation drivers. More particularly, FIG. 5 shows the modules used by the driver 50 in one embodiment to evaluate a response received from a promotion code provider 60 after a promotion code has been submitted. Upon receiving a validation response 52 from the promotion code provider 60, the driver 50 can initially store 54 the response in a buffer or memory 56. Next, the response can be evaluated 58 using a dictionary 59. The dictionary 59 can be built using machine learning to decipher responses from promotion code providers 60. For example, promotion code providers 60 may use a variety of responses to indicate that a promotion code is invalid. The data store 56 of FIG. 5 can be used to store evaluated responses.


As one example of the evaluation of a response 30 from the promotion code provider 60, the response from the promotion code provider 60 may read, “The promotional code you entered is not valid.” The validation driver must parse this response and interpret what it means—in this case, the proper interpretation is simply that the promotion code is not valid. In another example, the response from the promotion code provider 60 may read, “Error 555.” The validation driver may interpret this response to mean, for example, that the promotion code is not valid. In yet another example, the response from the promotion code provider 60 may read, “The promotional code you entered has expired.” The validation driver should interpret this response to mean that the promotion code was once valid, but has now expired. The validation algorithm uses natural language processing to score and weight a response from a provider. There are trigger words such as invalid, or not applicable, within the responses, that will indicate the validity of a promotion code. However, some of these mappings between response and validity may result in a new workflow. For example, if the validation algorithm detects that a coupon might be valid, given the right shopping cart contents, it will search for product descriptions that might lead to the coupon becoming valid. The goal of the system is to validate the coupon or offer, so attempting to find ways, such as selecting appropriate shopping cart contents is a valid course of action for the algorithm.


Thus, improved techniques for validating a promotion code have been described. The use of the method and apparatus can, for example, allow a large number of promotion codes to be validated in an efficient and timely manner that saves shoppers from having to go through a series of manual steps to determine whether a promotion code is valid.


Although the invention has been described and illustrated in the foregoing illustrative embodiments, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the details of implementation of the invention can he made without departing from the spirit and scope of the invention. Features of the disclosed embodiments can be combined and rearranged in various ways.

Claims
  • 1-19. (canceled)
  • 20. One or more tangible, non-transitory, machine-readable media storing instructions that, when executed by a computer, effectuate operations comprising: obtaining, with a computer, a first plurality of strings assigned to a test driver;identifying, with the computer, by the test driver, a first string-submission interface of a first website;causing, with the computer, by the test driver, testing of at least some of the first plurality of strings by causing submission of strings among the first plurality of strings via the first string-submission interface; andstoring, with the computer, at least some test results of the testing in memory.
  • 21. The one or more media of claim 20, wherein the operations further comprise: determining whether a first response to submission of a first string among the first plurality of strings indicates that the first string is effective to cause a numerical value in a webpage of the first website to decrease.
  • 22. The one or more media of claim 21, wherein the operations further comprise: controlling a web browser to simulate a user submission of a second string among the first plurality of strings.
  • 23. The one or more media of claim 22, wherein the operations further comprise: determining whether a second response to submission of the second string indicates that the second string is effective to cause the numerical value to decrease.
  • 24. The one or more media of claim 20, wherein: at least some of the first plurality of strings are assigned to the test driver by a test monitor configured to assign batches of strings to a plurality of test drivers.
  • 25. The one or more media of claim 24, wherein: the operations further comprise sending test results to the test monitor; andat least some of the first plurality of strings are selected by the test monitor based on previous test results sent to the test monitor.
  • 26. The one or more media of claim 20, wherein: at least some of the strings are caused to be submitted via a first website-specific application programming interface request.
  • 27. The one or more media of claim 20, wherein the operations comprise: obtaining a second plurality of strings;identifying, by another test driver, a second string-submission interface of a second website; andcausing, by the other test driver, testing of at least some of the second plurality of strings by causing submission of strings among the second plurality of strings via a second website-specific application programming interface request.
  • 28. The one or more media of claim 20, wherein the operations comprise: steps for controlling a web browser to simulate user actions interacting with web site.
  • 29. The one or more media of claim 20, wherein identifying the string-submission interface comprises: detecting an input text box in a given webpage of the website based at least in part on proximity of a first element in a document object model of the given webpage to a second element of the document object model, wherein: proximity is independent of layout; andthe second element includes or is a button interaction element.
  • 30. One or more tangible, non-transitory, machine-readable media storing instructions that, when executed by one or more processors, effectuate operations comprising: obtaining, with one or more processors, a first plurality of promotion codes assigned to a validation driver by a monitor;determining, with one or more processors, at least in part by the validation driver, how to submit the promotion codes by detecting a first promotion-code-entry webpage of a first merchant website and identifying a first promotion-code interface of the first promotion-code-entry webpage;testing, with one or more processors, by the validation driver, the first plurality of promotion codes by simulating user actions of submitting the first plurality of promotion codes via the first promotion-code interface and determining whether responses to the submissions indicate respective promotion codes are valid; andstoring, with one or more processors, at least some test results of the testing in memory.
  • 31. The one or more media of claim 30, wherein: the first plurality of promotion codes are assigned based on at least some test results from another test of promotion codes.
  • 32. The one or more media of claim 30, wherein the operations further comprise: determining that a given promotion code requires that a given product be in a shopping cart at checkout and, after testing validity of another promotion code causes the shopping cart to cease to include the given product, re-adding the product to the shopping cart.
  • 33. The one or more media of claim 30, wherein: some promotion codes in the first plurality of promotion codes are asynchronously tested for validity.
  • 34. The one or more media of claim 30, wherein the operations further comprise: causing a JSON object containing validation data indicative of test results to be passed to the monitor.
  • 35. The one or more media of claim 30, wherein: the validation driver is configured to detect changes in webpages relative to previous versions of webpages.
  • 36. The one or more media of claim 30, wherein: the operations further comprise controlling a web browser through an automation application programming interface.
  • 37. The one or more media of claim 30, wherein the operations further comprise: detecting a first promotion-code input text box based at least in part on proximity of a first element of a document object model of the first promotion-code-entry webpage to a second element of the document object model, wherein the first promotion-code input text box is identified as the first promotion-code interface.
  • 38. The one or more media of claim 37, wherein proximity is determined based on proximity in the document object model and is independent of layout.
  • 39. The one or more media of claim 37, wherein proximity is determined based on proximity to a button interaction element and the second element includes or is the button interaction element.
  • 40. The one or more media of claim 30, wherein: the operations further comprise detecting a first promotion-code input text box based at least in part on proximity of nodes in a graph data structure; andproximity is determined based at least in part on a union of two nodes in the graph data structure, the graph data structure specifying relationships between webpage elements of the detected promotion-code-entry webpage.
  • 41. The one or more media of claim 30, wherein simulating user actions of submitting the first plurality of promotion codes comprises: steps for controlling an interface that simulates user actions.
  • 42. The one or more media of claim 30, wherein the operations comprise: limiting promotion-code validation testing based on a merchant-specific throttling pattern and historical validation rate data.
  • 43. The one or more media of claim 30, wherein the operations comprise: steps for evaluating a response from a promotion-code provider.
  • 44. The one or more media of claim 30, wherein the operations comprise: causing, by the validation driver, testing of a second plurality of promotion codes on a second merchant website, wherein the first merchant website and the second merchant website use different terminology in responses to promotion-code submissions to indicate whether promotion codes are valid.
  • 45. The one or more media of claim 30, wherein the validation driver is configured to automatically test validity of promotion codes and, in response to test results, cause an online shopper to receive a promotion code that test results indicate are valid.
  • 46. A method, comprising: obtaining, with a computer, a first plurality of promotion codes assigned to a validation driver by a monitor;determining, with the computer, at least in part by the validation driver, how to submit the promotion codes by detecting a first promotion-code-entry webpage of a first merchant website and identifying a first promotion-code interface of the first promotion-code-entry webpage;testing, with the computer, by the validation driver, the first plurality of promotion codes by simulating user actions of submitting the first plurality of promotion codes via the first promotion-code interface and determining whether responses to the submissions indicate respective promotion codes are valid; andstoring, with the computer, at least some test results of the testing in memory.
  • 47. The method of claim 46, wherein: the first plurality of promotion codes are assigned based on at least some test results from another test of promotion codes.
  • 48. The method of claim 46, comprising: causing, by the validation driver, testing of a second plurality of promotion codes on a second merchant website, wherein the first merchant website and the second merchant website use different terminology in responses to promotion-code submissions to indicate whether promotion codes are valid.
  • 49. The method of claim 46, comprising: causing a JSON object containing validation data indicative of test results to be passed to the monitor.
Continuations (2)
Number Date Country
Parent 15592807 May 2017 US
Child 16245021 US
Parent 13307586 Nov 2011 US
Child 15592807 US