In recent years e-commerce platforms have massively scaled and continue to do so. Accordingly, efficient use of network and computing resources is suffering leading to waste.
An aspect of the specification provides a feedback apparatus and method for dynamically controlling e-commerce platforms comprising a central engine is configured to connect with an e-commerce platform associated with a plurality of communication devices and a plurality of engagement engines and fulfillment engines that interact with the communication devices; the central engine is configured to dynamically add, remove or adjust the computational resources in the e-commerce platform in order to achieve a target efficiency for engagements with the communication devices and fulfillments from the communication devices.
Various embodiments of the present invention will now be discussed, by way of example only, with reference to the attached figures.
Various embodiments of the present invention will now be discussed, by way of example only, with reference to the attached figures.
The above-mentioned aspects will be understood by the discussion below in relation to certain non-limiting example embodiments. Such example embodiments are described with reference to certain systems, devices, methods and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a special purpose and unique machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. The methods and processes set forth herein need not, in some embodiments, be performed in the exact sequence as shown and likewise various blocks may be performed in parallel rather than in sequence. Accordingly, the elements of methods and processes are referred to herein as “blocks” rather than “steps.”
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions, which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus that may be on or off-premises, or may be accessed via the cloud in any of a software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS) architecture so as to cause operational blocks to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions, which execute on the computer or other programmable apparatus, provide blocks for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. It is contemplated that any part of any aspect or embodiment discussed in this specification can be implemented or combined with other aspects or embodiments discussed in this specification.
Various advantages and features consistent with the present specification will become apparent from the following description with reference to the drawings.
Referring now to
Central engine 104 is also connectable to at least one e-commerce platform 112. As used herein, e-commerce platform 112 comprises a plurality of computing engines 116, including at least one engagement engine 116-E and at least one fulfilment engine 116-F. (It is to be emphasized that while a plurality of engagement engines 116-E and fulfillment engines 116-F are shown in
Referring now to
Engine 104 includes at least one input device which in a present embodiment includes a keyboard 204. (In variants, other input devices are contemplated.) Input from keyboard 204 is received at a processor 208. In variations, processor 208 can be implemented as a plurality of processors. Processor 208 can be configured to execute different programing instructions that can be responsive to the input received via the one or more input devices. To fulfill its programming functions, processor 208 is configured to communicate with at least one non-volatile storage unit 216 (e.g., Erasable Electronic Programmable Read Only Memory (“EEPROM”), Flash Memory, Hard-disk) and at least one volatile storage unit 216 (e.g., random access memory (RAM)). Programming instructions (e.g. applications 224) that implement the functional teachings of engine 104 as described herein are typically maintained, persistently, in non-volatile storage unit 216 and used by processor 208 which makes appropriate utilization of volatile storage 220 during the execution of such programming instructions.
Processor 208 in turn is also configured to control display 212 and any other output devices that may be provided in engine 104, also in accordance with different programming instructions and responsive to different input received from the input devices.
Processor 208 also connects to a network interface 236, for connecting to network 106. Network interface 236 can thus be generalized as a further input/output device that can be utilized by processor 208 to fulfill various programming instructions.
As will become further apparent below, engine 104 can be implemented with different configurations than described, omitting certain input devices, or including extra input devices, and likewise omitting certain output devices or including extra output devices. For example, keyboard 204 and display 212 can be omitted where engine 104 is implemented in a data center, with such devices being implemented via an external terminal or terminal application that connects to engine 104.
In a present embodiment, engine 104 is configured to maintain, within non-volatile storage 216, datasets 228 and applications 224. Datasets 228 and applications 224 can be pre-stored in non-volatile storage 216 or downloaded via network interface 236 and saved on non-volatile storage 216. Processor 208 is configured to execute applications 224, which accesses datasets 228, accessing non-volatile storage 216 and volatile storage 220 as needed. As noted above, and as will be discussed in greater detail below, processor 208, when executing applications 224, controls e-commerce platform 112 and its interactions with devices 108.
Referring now to
Processor 304 is also configured to control display 316 and speaker 320 and any other output devices that may be provided in device 108, also in accordance with programming instructions and responsive to different input from the input devices.
Processor 304 also connects to a network interface 324, for connecting to network 106. Network interface 324 can thus be generalized as a further input/output device that can be utilized by processor 304 to fulfill various programming instructions.
As will now be understood, device 108 can be of a variety of form factors including a laptop computer, mobile telephone, table computer, desktop computer or the like. Device 108 can be implemented with different configurations than described, omitting certain input devices, or including extra input devices, and likewise omitting certain output devices or including extra output devices.
Processor 304 is configured to bi-directionally communicate with e-commerce platform 112, via network interface 324 and network 106, accessing non-volatile storage 308 and volatile storage 312 as needed.
Turning now to e-commerce platform 112 and computing engines 116 in
In a variant, it is to be understood that one or more proprietary engagement engines 116-E and/or one or more proprietary fulfillment engines 116-F can be built directly into engine 104 as a complete embodiment according to the present specification.
To further assist in understanding system 100, reference will now be made to
Thus, the functionality and programming behind method 400 implements a schema of key performance indicators (KPI). Hereafter a schema may be referred to as a KPI Schema. Block 404 through Block 432 can be implemented in a variety of ways, from hard coding to an elegant graphical interface that expresses requested inputs in terms of known business language such as “Goals”, “Critical Success Factors”, and “Key Performance Indicators”. In a presently preferred embodiment, such a graphical interface utilizes a concept of a Key Performance Indicator Schema or “KPI Schema”.
A KPI Schema enables the ability to track business performance by identifying, managing and visualizing important metrics and tracking them against actual performance Many people and processes are involved in delivering on corporate goals. A KPI Schema creates hierarchical structures to describe the logical relationships and the many activities needed to accomplish those goals.
Schemas will be created and edited in a standard browser on a desktop computer. Schemas can then be shared and interacted with on a desktop computer using a browser. Ideally, a mobile app will also be made available, but that is not part of this initial development.
A KPI Schema enables several concepts.
The system provides the ability for a new user to create an account or login to an existing one via a secure, password-protected sign-in process. Users can then build interactive hierarchical Schemas to illustrate what metrics are being tracked. Schemas and Branches can be saved, reused, and shared with others.
The interface of KPI Schema supports several modern browsers such: Chrome, Safari, Edge and Firefox.
User Interactions
There can, in certain embodiments, be two types of users of system 100.
At the start of any session, user will be asked “what would you like to do?” and presented with 2 options:
User will first be asked to name the Schema. By default, New Schema will be in Name field, such as below.
The user begins by identifying the Goal and then CSF (Critical Success Factors) and moves down the vertical tree but they can also start with a known KPI if they already have them identified. They can fill in the missing pieces as they decide on them. The Schema structure will help them justify the chosen KPIs.
At each field level, the system 100 can prompt user to create a new Node, such as a CSF. Once done, they will be asked if they want to create another Node of the same type (i.e. another CSF) or if they want to continue to next phase. In this case the Sales Phase. The user also has the option of creating new and additional layers as they require.
The Schema can be saved and shared at any time. i.e. it does not have to be complete with all levels completed.
A sandbox is available as a bin of “stuff to possibly use” off to the side of the Schema. The user can enter things there as a “card” or something then drag them into the Schema when they figure out where they go. Likewise, if they're reviewing an existing Schema and feel an entry isn't quite right, they can drag it to the sandbox to put it on hold until they figure out where it really belongs. The sandbox should be saved between sessions so people can pick up where they left.
Note: D3.js is a JavaScript library for producing dynamic, interactive data visualizations in web browsers. In the first development effort, it was used as the interface and creation of Schemas. It makes use of Scalable Vector Graphics, HTML5, and Cascading Style Sheets standards. It is not a requirement that D3 be used, but it is essential that a JavaScript library be used instead of creating code from scratch.
Branches
Branches are any self-contained sections of the Schema. Information and the intellectual property of the branch can be reused to bring new capabilities or structures into a Schema.
For example, if an organization wants to establish or upgrade their digital marketing capability, they could locate an appropriate branch by browsing the inventory and matching the capability they are looking for. They can then simply drag that branch onto their canvas and attach it wherever appropriate. They could then assign users to each Node.
Inventory
Inventory are areas to store and access Schemas, Branches, measures and metrics. Corporations can use branches as a way of developing and re-using their ideas instead of continually reinventing and recreating the same structures.
Users can create a new branch by adding individual nodes or branches and saving that structure as a new branch.
The image in
TABLE I below simulates the interaction between user and the system in the building of a new Schema. The system provides an interactive experience when creating a Schema, by guiding the user through the hierarchical levels.
For example, the user should be told to identify a Goal, and be given a Definition for the Goal and then also Examples as they ask for more information. We have listed initial values for the Definition and Examples, but these must be easily modified by a non-developer on the KPI Schema marketing team. i.e. does not require a Developer. Modifications to these definitions and examples can be modified by Editors of customer and/or by KPI Schema staff. Customers may want to add in their own examples to make it customizable for their company.
Annotations and Tags
Just as users are guided in the creation of Branches and Nodes, they will have the ability to modify, delete and add new annotations which are attached to any Node or Branch. This allows users to share ideas with others or set as reminders for themselves of what was done.
The system needs to support annotations and tags. Users will have the ability to attach to a Node or Branch. This could be a sentence or paragraph to assist in describing something about it.
For tags, a list of accounts will populate when you use the @ tag, and popular hashtags will populate when you use the #tag. When the account or topic appears, the user can select it from a drop-down list.
KPI Input
Identified KPIs can either be a precise Measure or a calculated Metric. Both are acceptable as inputs in the Karta. For example, it can be expressed as a Measure such as:
Or it can be expressed a calculated Metric such as:
Once a user has identified a KPI to track, the users will have the ability to enter a numerical value in an input field for KPI Target. An additional free-form field will allow user to indicate the Relative type of the Target value used. For example, they can state it is a Monthly target, or a percentage increase over last week's target.
An Editor of Schemas will be able to enter the formula behind the metric. And there will be a way of testing the formula and input sample values to make sure they get a value they are expecting. This will require a way to notate “fields” (i.e., measures) that feed the formula. Something like:
“Percentage increase in outbound phone calls from prior month” would be:
(([Number of Outbound Phone Calls]/[Number of Months])−[Previous Month Average Outbound Phone Calls per Month])/[Previous Month Average Outbound Phone Calls per Month]
System needs to show Editor that math formula validates as it is entered. Likely with a green checkmark to indicate it is correct. Guidance needs to be provided to users in the form of help screens.
Input
User will be able to enter how many of each metric they have completed in a set period. For example, if the Target value for a KPI is 10, they can input that they did 8 and the system would calculate that they reached 80% of the objective for that KPI. Users can define values to two decimal points, as a “percentage with two decimal places” a “percentage with zero decimal places” a “whole number (i.e., integer)” a “fractional number (i.e., decimal)”.
The user will be able to define what the period is to properly calculate progress. If the goal is 10, the current progress is 8, but you're at 2 days into a one-month period, you're actually way ahead of the goal. Stating an attainment value in terms of year-to-date, or perhaps as progress-to-date is important.
Color coding will show progress. For example, Red might be 50% or less, yellow 51%-99% and 100%+ being green. The thresholds will be user-defined and changeable.
The user will be able to update all fields from an Excel, CSV or other input file.
The example below illustrates how D3 can be used to show attainment of KPI Targets expressed as a percentage. If in this example, Breaded Chicken Breasts had a Target value of 200 and 180 was reached, it will show a 90% completion. Breaded Chicken Breasts, Chicken Wings and Chicken Pie are all part of Poultry, and the average attainment of the group is shown as 54%. (The finished graphical too can have Schemas illustrated top to bottom, or left to right as in
Data Export
There should be the facility to export data from the Schema as an Excel file or standard text. The two formats are:
Each branch and each KPI may not be of equal importance. Some activities are more critical to complete. Therefore, users can set weightings on the nodes for branches or KPIs. For example, if 4 nodes are part of one branch, the user will have the ability to say that one is worth 50% because it's more important and the system then assigns 16.7% to the remaining 3. Further, the user can state that a second node is worth 20% and the system will then assign 15% to the remaining 2. This weighting will be inhered up the Schema.
Managing Elements
User can inventory Elements (Inventory, Schemas, Branches, measures and metrics) so they can be accessed, shared, modified and reused. The system will track who made changes, include date and time stamp, and maintain a history of changes.
An Element is owned by one User. Elements can be transferred to another user. This is important because it means if a user opts to delete their account, their Schemas need to be deleted, or transferred. The Elements they own could be transferred to the “account administrator” as a last resort.
Per Table II, Elements can be tagged as Private, Department, Corporate or Public.
Schemas can be saved with option for “Save As” to duplicate and create new.
Schemas can be sent to others. By identifying an email address to share a Schema with, the system will send a notification and invitation to that new user to access the Schema by signing up for service.
Full security must be in place to ensure authorized user access only.
Multiuser—accommodates multiple user updates and provides real-time views of projects. Users simply refresh their browser to see any updates from other users. This could possibly be done real time and interactively within the interface itself.
Version Control
Version Control, Journaling and Roll Back/undo—permits unlimited rollback from the time a particular goal was last accessed. This journaling functionality allows the user to click and roll back individual actions and then apply those changes individually again by rolling forward. This allows someone to “label” a version and roll back to it if needed. For example, label a Schema as 2.0, then realize it's incorrect and reset the Schema back to the 1.0 version. This would be extremely important for organizations, and likely even useful for individuals.
Branches
It should be possible to save Schema Branches for reuse in another Schema.
This will require that Branch is named and accessible by that author only or by his designated team by same designation; Private, Corporate, Public. Public Branches and Schemas can potentially be available in a Marketplace for others to access.
User Interactions
System will notify users when a Schema they are active with has been updated. An update can be a change to a branch, KPI or target. Notifications can be done via email or some social media method. It should also be possible to send automated reminders for users to complete portions of the Schema such as filling in their performance numbers.
Where Used
Allows a user to see where a Branch has been used in other Schemas.
Allows a user to see where a KPI has been used in other Schemas. If a KPI such as Calls/Month is created, it should be possible to view where that same KPI has been used in other Schemas that are available to user.
Monitoring Performance and Input Screen
All KPI information can be accessed from the Schema map by investigating KPI nodes to see who is working on them and so on.
But users will also have access to a single screen where they can see all KPIs that have been established for themselves as well as for other staff. Here they can see what the KPIs are and their targets and how they are performing against them and what the edit date was for each.
A filter will show only the ones they are responsible for or they can see all. Filtering and sorting will allow the viewing of specific individuals, KPI performance as well as dates of latest updates.
The sharing of numbers by others must be approved by individuals just as Outlook calendars are shared.
This view also acts as the input screen to update their performance values. Changing a value in the input screen will update the value in the Schema.
Reminders will also be available to encourage people to complete their numbers in a timely fashion and to let them know if they are missing their targets.
Schema Marketplace
Users can publish their Schemas in the Public space and offer their consulting services to others.
Thus having completed block 404 through block 432, at block 436 a content selection is made based on the relevant node of the KPI Schema and generated via a selected engagement engine 116-E to an associated one or more communication devices 108 which have been brought into engagement, or are being brought into engagement, with e-commerce platform 112. At block 440 the selected is delivered to the associated communication device 108. At block 444, content responses, according to a relevant branch and/or node, as the context requires are measured, according to the selected weightings of the KPI Schema.
Block 448 comprises determining differences between the measurements at block 444 and the goals and associated KPI metrics found in the relevant schema.
Block 452 determines whether the goals have been achieved. The determination need not be absolute, but rather an approximation or an approaching of the goals may be sufficient to obtain a “yes” determination at block 452. By the same token a “no” determination leads to block 456 at which point the resources allocated to e-commerce platform 112 are adjusted dynamically to attempt another iteration towards fulfillment of the goals from block 404 and the critical success factors of block 408. By removing unproductive engines 116 from platform 112, computing resources and bandwidth across all computing elements of system 100 are preserved, as only engines 116 which lead to maximum communication between communication devices 108 and e-commerce platform 112 are preserved within system 100.
Another aspect of this specification provides for generation of a graphical user interface in the form of a dashboard for controlling an e-commerce platform. The generation can be affected by a method and/or stored as a set of programming instructions to implement the method on a computer readable medium. The result of the generation creates a new apparatus for controlling an e-commerce platform.
In a present embodiment, dashboard 1000 is generated on display 212 of engine 104 and various portions of dashboard 1000 can be adjusted automatically and/or manually via keyboard 204 (and/or other input device). Dashboard 1000 includes schema 500, or a variant thereon.
In
Each aggregation field level 504-A can be configured as described earlier to progressively aggregate KPI information into a single top level 504-A-1, currently defined as a “Goal”. Engine 104 can be configured to control various engines 116 to induce interactions with devices 108, iteratively, to thereby affect KPIs at KPI level 504-K to direct the “Goal” towards achievement.
As labelled in
For simplicity of providing an illustrative example, level 504-1, level 504-2 and level 504-3 are logically the same, but a person skilled in the art will appreciate that level 504-2 can have multiple nodes 512 and that level 504-3 can have multiple nodes 512.
Nodes 512-5 all correspond directly to one or more of the engines 116. To elaborate, node 512-5-3 and node 512-5-7 are each labelled “Google” making them correspond directly with our earlier example of Google being engagement engine 116-E-1. Furthermore, node 512-5-4 and node 512-5-8 are each labelled “Facebook” making them correspond directly with our earlier example of Facebook being engagement engine 116-E-2. By the same token, node 512-5-1 and node 512-5-5 are each labelled “Amazon” making them correspond directly with our earlier example of Amazon being fulfillment engine 116-F-1. Furthermore, node 512-5-2 and node 512-5-6 are each labelled “Wayfair” making them correspond directly with our earlier example of Wayfair being fulfilment engine 116-F-2. While not shown, additional engines 116 can be included on dashboard 1000, with the corresponding feedback and control that is discussed further herein. (Dashboard 1000 is therefore also compatible with different e-commerce platforms 112.)
A plurality of fulfillment indicators 516 are also provided, with one indicator 516 being respective to a given node 512. (In
Through another interface, not shown, such as a dialogue box activated by using a pointing device to highlight the indicator 516-K or the node 512-K, the numerator and denominator of the fulfillment indicators 516-K can be established. Likewise, if desired, a time period over which such numerators and denominators can be defined, the completion of such a time period (e.g. weekly, monthly, quarterly, yearly) defining when indicators 516 are updated. The denominator of indicators 516-K represent a KPI target, while the numerators represent an actual fulfillment of that target over the relevant time period. In a present embodiment, such numerators and denominators are only provided for indicators 516-K, those indicators 516-K representing what performance is being measured.
Thus, the indicators 516 respective to each node 512—in the field level 504-P and up through field level 504-A to field level 504-1 represent progressive aggregations of the indicators 516-K all the way up to field level 504-1 and ultimately to indicator 516-1 of node 512-1. To elaborate through example, indicator 516-P-1 combines the values of indicator 516-K-1 and indicator 516-K-2. Indicator 516-5-1, likewise, combines the values of indicator 516-P-1 and indicator 516-P-2. And so on.
In some embodiments, the combination of a given parent node 512 is an average of the values in the indicators 516 in the child nodes 512 directly below the given parent node 512. In a presently preferred embodiment, however, each edge 508 can be assigned a relative weighting as compared to another edge 508 depending from the same parent node 512. This relative weighting can be assigned through another dialogue box (not shown) that can be accessed by selecting the relevant edge 508 or node 512 depending from the edge 508. According to this preferred embodiment, edges 508 can be shown also with a relative thickness proportional to their weighting. As a specific example, edge 508-3-1 is much thicker than edge 508-3-2. According to this example, node 512-4-1 has a weighting of 90%, whereas node 512-4-2 has a weighting of ten percent (10%). This means that in indicator 512-3, the calculated value will be based on 90 percent of the value of indicator 516-4-1 and 10 percent of the value of indicator 516-4-2.
While the foregoing has discussed certain specific embodiments, it is to be understood that variants, combinations and/or subsets of those embodiments are contemplated. For example, the foregoing can be applied to KPI systems across a variety of domains including human resources, to track and set targets for KPIs such as Attendance vs combatting absenteeism, rates of alcoholism, number of recruiting referrals. Another domain includes with KPIS such as shipping times, shipping cost per tonnage. Another domain includes civil engineering projects with KPS such as material delivery times, adherence to scheduling, quality control verification. Another domain includes manufacturing, with KPIs such as defects per unit, number of units produced over a given time period, and labor costs per unit manufactured. In some aspects of this specification, some domains can be fully automated using system 100, while other aspects can benefit from the graphical interface embodiments.
At this point it bears repeating that dashboard 1000 is implemented on central engine 104 to establish certain control parameters over e-commerce platform 112. Dashboard 1000 provides a convenient means to set up a holistic campaign to, for example, sell a product on fulfillment engines 116-F using engagement engines 116-E to generate content on devices 108 that will divert traffic on network 106 from device 108 to fulfillment engines 116-F so that interactions can be made between devices 108 and fulfilment engines 116-F to effect an electronic purchase transaction of the product.
According to the example in
The language used to identify each node 512 throughout the remaining field levels 504 of dashboard 1000 is similarly “user-friendly”, expressed in language familiar to sales professionals without requiring the sales professional to have deep technical knowledge of system 100. Accordingly, dashboard 1000 also includes a Segment (at field level 504-A-4), which defines two markets, namely, the USA (at node 512-4-1) and Canada (at node 512-4-2). (The sales professional may also choose to label field level 504-A-3 as “Country” or “Market” instead of “Segment”; again it is entirely within the control of the sales professional to configure the wording of each field level 504 and node 512 and weightings of each edge 508 as they see fit to conform with their conceptualization of the product sales process.) As noted above, edge 508-3-1 respective to USA node 512-4-1 is weighted at 90%, whereas edge 508-3-2 respective the Canada node 512-4-2 is weighted at 10%, to reflect the relative size of each market. In other words, behaviours of nodes below node 512-4-2 will have only 10% impact on the value of the indicator 516-1 for goal node 512-1 since the Canadian market is only 1/10 the size of the US market.
Continuing down the branches from “Segment” field level 504-A-4, the “Approach” field level 504-A-5 includes a “Fulfill” node 512-5-1 and an “Engage” node 512-5-1 under the “USA” node 512-4-1; likewise, the “Approach” field level 504-A-5 includes a “Fulfill” node 512-5-3 and an “Engage” node 512-5-4 under the “Canada” node 512-4-2. Fulfill represents the sales of the product, and hence edge 508-4-1 and edge 508-4-3 each have ninety percent weightings compared to Engage which represents advertising or promotion of product, and hence edge 508-4-2 and edge 508-4-4 each have ten percent weightings. (The increased weighting due to the fact that, from the perspective of the sales professional, an actual sale or “Fulfillment” drives the “Revenue” goal at node 512-1 more than the promotion or “Engagement”, and yet promotion is important to drive sales.)
The label “Fulfill” is thus chosen by the user of dashboard 1000, to mean fulfilments of sales. Again, the label “Fulfill” could be any equivalent that is friendly to the user, such as “Sales” or “Conversions”; it is friendly to the user and otherwise agnostic to the technical functioning of engine 104. Nonetheless, it can be reiterated that such user friendliness reduces the time to, and improves the accuracy of, the configuration of system 100; without such user friendliness in dashboard 1000, communications between devices 108 and platform 112 may include more wasted generations of promotions on devices 108 from engagement engines 116-E that do not lead to actual diversions to fulfillment engines 116-F. This in turn leads to wastage of resources on network 106 and platform 112 and devices 108. System 100 mitigates such wastage.
Continuing down the branches of dashboard 1000 from “Approach” field level 504-A-5, the “Platform” field level 504-P includes an “Amazon” node 512-P-1 and a “Wayfair” node 512-P-2 under the “Fulfill” node 512-5-1; likewise, the “Platform” field level 504-P includes a “Google” node 512-P-3 and a “Facebook” node 512-P-4 under the “Engage” node 512-5-1. (All of which are under “USA” node 512-4-1.) By the same token, the “Platform” field level 504-P includes an “Amazon” node 512-P-5 and a “Wayfair” node 512-P-6 under the “Fulfill” node 512-5-3; likewise, the “Platform” field level 504-P includes a “Google” node 512-P-7 and a “Facebook” node 512-P-8 under the “Engage” node 512-5-4. (All of which are under “Canada” node 512-4-2.)
As will now be understood from the earlier discussions, edges 508-5, respective to nodes 512-P, can be assigned any desired relative weightings according to the respective value of each engine 116 according to the sales professional operating dashboard 1000.
Continuing down the branches of dashboard 1000 from “Platform” field level 504-P, the “KPI” field level 504-K includes a “Search” node 512-K-1 and an “Orders” node 512-K-2 under the “Amazon” node 512-P-1; likewise “KPI” field level 504-K includes a “Search” node 512-K-3 and an “Orders” node 512-K-4 under the “Wayfair” node 512-P-2. (All of which are under “Fulfill” node 512-5-1.) By the same token, the “KPI” field level 504-K includes an “Amazon” node 512-K-5 and a “Wayfair” node 512-K-6 under the “Google” node 512-P-3; likewise “KPI” field level 504-K includes a “Amazon” node 512-K-7 and an “Wayfair” node 512-K-8 under the “Facebook” node 512-P-4. (All of which are under “Engage” node 512-5-2.)
Note that node 512-K-1, node 512-K-2, node 512-K-3 . . . node 512-K-8 are all under the “USA” node 512-4-1, and that a sales professional user of dashboard 1000 can readily visualize that fact due to the graphical layout of dashboard 1000. By the same token, node 512-K-9, node 512-K-10, node 512-K-11 . . . node 512-K-16 are under the “Canada” node 512-4-2, but are otherwise have a common name and function to their respective node 512-K-1, node 512-K-2, node 512-K-3 . . . node 512-K-8. Accordingly, a user of dashboard 1000 can readily visualize the relative performance of each KPI node 512-K in relation to the nodes 512 as they move up the hierarchy of field levels 504.
In an embodiment of the invention, the data in nodes 512-K can be populated, automatically, via one or more application programming interfaces (“API”) from central engine 104 to the reporting tools available in engines 116-E and engines 116-F. To elaborate:
A person of skill in the art will now appreciate that the user sales professional of dashboard 1000 can, through other interfaces on central engine 104, or elsewhere, define and directly control the creation and online advertising or other promotional campaigns on engagement engines 116-E for the product in question. For example, search engine optimization (“SEO”) techniques can be employed to cause the product to appear in organic searches on Google (engine 116-E-1) or to appear in organic social media content on Facebook (engine 116-E-2). Carefully crafted blog posts, videos, or other content that feature the product can cause the product to appear in organic searches on Google on devices 108. Or, social media promoters on Facebook can be engaged to promote organic content related to the product can be effected on Facebook as accessed by device 108. Instead of organic searches, Google Ads or Facebook Ads can be directly employed, to push advertising content of the product directly onto devices 108. Engagement content on engagement engines 116-E can in turn cause users (if deemed relevant by those users) of devices 108 to connect directly to the Amazon fulfillment engine 116-F-1 or Wayfair fulfillment engine 116-2. Thus, KPIs respective to node 512-K-5, node 512-K-6, node 512-K-7, node 512-K-8, node 512-K-13, node 512-K-14, node 512-K-15, and, node 512-K-16 can be impacted through the control of such campaigns, according to the responses by users of device 108 receiving those campaigns. Additional KPI nodes 512-K could be included in dashboard 1000, that include organic searches vs advertisements for each of Google and Facebook, to provide further granularity in dashboard 1000 and the resulting automated control over platform 112, as desired. Still further KPI nodes 512-K can be included for impressions vs clicks under each of those organic campaigns vs advertising campaigns. For simplicity of illustration, however, dashboard 1000 only includes the nodes 512 as shown.
While dashboard 1000 can effect direct control over content campaigns delivered via engagement engines 116-E, it is the actions of users of devices 108 in relation to fulfillment engine 116-F that drive KPI performance of fulfillment nodes 512 including node 512-K-1, node 512-K-2, node 512-K-3, node 512-K-4, node 512-K-9, node 512-K-10, node 512-K-11, and, node 512-K-12. Orders received and tracked via node 512-K-2, node 512-K-4, node 512-K-10, and, node 512-K-12 are of particular interest in efforts to drive indicator 516-1 towards one-hundred-percent, and higher, if possible. Dashboard 1000 thus provides the options for manual and fully automated control over delivery of campaigns via engagement engines 116-E to increase and ideally maximize orders received via fulfillment engines 116-F. In this fashion, campaigns that do not translate into orders received via fulfillment engines 116-F can be removed from engagement engines 116-E, thereby eliminating those engagement engines 116-E from system 100, thereby relieving computational and network resource strain on engagement engines 116-E, devices 108 and network 106.
It can also be noted that dashboard 1000 includes a date field 1002, which indicates that state of dashboard 1000 given the state of various KPI nodes 516-K on that day. In
Referring now to
(
In lay terms for the user of dashboard 1000, between July 14 and July 15, a campaign has been pushed out on Facebook engagement engine 116-E-2 that promotes the product on Wayfair fulfillment engine 116-F-2. This has resulted in an increase in the number of orders on the Wayfair fulfillment engine 116-F-2, thereby improving that KPI and ultimately improving revenue. Again, it can be noted that such a campaign can be “turned on” automatically by central engine 104 sending an instruction to fulfillment engine 116-F-2 as a result of thresholds or other criteria for increasing or otherwise varying one or more indicators 516 that are configured in dashboard 1000 and central engine 104.
It is thus to be understood that dashboard 1000 includes a graphical interface with a tree structure, where each parent node's (i.e. nodes 512-P and upwards) value is derived from a specific formula applied to the values of its child nodes. This computed value not only characterizes the relationship between a parent node 512 and its immediate child nodes 512 but also influences the value at the upper field levels 504. Consequently, through recursive application of this formula from the leaves towards the root, the computed values propagate upwards, culminating in the determination of the root node's (i.e. node 512-1) value. This process embodies a bottom-up computation, with each node 512 serving as a building block for the value of its ancestors, ultimately shaping the overall tree structure and the root node's value. This concept applies even if there are only two levels 504, including a root node 512-1 and a plurality of KPI nodes 504-K.
A person of skill in the art will now appreciate how this very specific but non-limiting example demonstrates the overall scalability and flexibility of system 100 and related teachings herein, to provide a graphical interface that allows for the establishment of targets and KPIs that can be used by non-technical business analysts, while also effecting a significant amount of very complex control over the technological resources of e-commerce platform 112 and streamlining utilization of e-commerce platform 112 towards technological efficient use of network resources as well as server and client device resources. Such controls over e-commerce platform 112 can be highly automated by establishing the nodes 512 and edges 508 of the dashboard 1000, campaigns that can be deployed on engagement engines 116-E, and KPIs at nodes 512-K. Engine 104 can thus automatically adjust campaigns across platform 112 to strive and achieve a “Goal” indicator 516-1 (or other label for field level 504-A-1) that is as high as possible, and ideally over one-hundred-percent, while also trying to reduce and/or minimize utilization of campaigns on engagement engines 116-E. What is notable is that dashboard 1000 itself, is highly customizable according to the underlying infrastructure of e-commerce platform 112, regardless of the technological complexity of the infrastructure, but meanwhile a non-technical business analyst or other user of dashboard 1000 can control e-commerce platform 112 at massive scale, allowing e-commerce platform 112 itself to optimize utilization of e-commerce platform 112 resources.
The use of machine learning can further augment performance of engine 104, as a plurality of campaigns can be administered and therefrom monitored and used to train a machine learning model to more quickly adjust utilization of e-commerce platform 112 resources towards an efficient steady state.
There can be one or more machine-learning algorithms and/or deep learning algorithms and/or neural networks of each application for system 100, which may include, but are not limited to: a generalized linear regression algorithm; a random forest algorithm; a support vector machine algorithm; a gradient boosting regression algorithm; a decision tree algorithm; a generalized additive model; neural network algorithms; deep learning algorithms; evolutionary programming algorithms; Bayesian inference algorithms; reinforcement learning algorithms, and the like. However, generalized linear regression algorithms, random forest algorithms, support vector machine algorithms, gradient boosting regression algorithms, decision tree algorithms, generalized additive models, and the like may be preferred over neural network algorithms, deep learning algorithms, evolutionary programming algorithms, and the like. However, to be clear, any suitable machine-learning algorithm and/or deep learning algorithm and/or neural network is within scope of the present specification.
Referring now to
Block 2004 comprises receiving a root node goal definition. The aforementioned description of dashboard 1000 in relation to node 512-1 is a non-limiting example of how block 2004 can be effected.
Block 2008 comprises receiving additional nodes, edges and respective layers. The aforementioned description of dashboard 1000 in relation to field level 504-A-2, level 504-A-3, level 504-A-4, level 504-A-5, level 504-P and level 504-K is a non-limiting example of how block 2008 can be effected. Again, note however that the number of levels 504 between the root node level 504-A-1 and the KPI level 504-K is variable—indeed there may be no additional layers if desired, simply having a root node level 504-A-1 and a KPI level 504-K. Weightings can be assigned to each of the edges 508 that connect these nodes 512, as previously discussed.
Block 2012 comprises receiving KPI parameters. The aforementioned description of building nodes 512-K along level 504-K is a non-limiting example of performance of block 2012. Notably, parameters are provided for indicators 516-K, such as a numerator that indicates an actual performance of an activity, and a denominator that indicates a target number of performances of that activity. Date ranges may be associated with these parameters, as discussed earlier.
Block 2016 comprises receiving KPI values. Block 2016 contemplates, for example, the population of numerators within any prescribed time periods, to obtain the actual performance of activities so that they can be compared to a target number of performances and deliver a quantified performance indicator.
Block 2020 comprises generating an interface. Again, dashboard 1000 and its various iterations discussed above are non-limiting example performance of block 2020. An initial performance of block 2020 corresponds to the dashboard 1000 in
Block 2024 comprises determining if the goals have been achieved. In our example, block 2024 comprises determining if the goal of 100% at the root node from block 2004 has been achieved. According to our earlier example, a “yes” determination might be made for Jul. 17, 2022 in
Block 2028 comprises adjusting resources if a “no” determination was made at block 2024. As noted above, an example of adjusting resources can include changing the campaigns at engagement engines 116-E as noted in relation to
As noted, machine learning can be applied at block 2024 and/or block 2028 to support automation.
As will now be apparent from this detailed description, the operations and functions of electronic computing devices described herein are sufficiently complex as to require their implementation on a computer system, and cannot be performed, as a practical matter, in the human mind. Electronic computing devices such as set forth herein are understood as requiring and providing speed and accuracy and complexity management that are not obtainable by human mental steps, in addition to the inherently digital nature of such operations (e.g., a human mind cannot interface directly with RAM or other digital storage, cannot transmit or receive electronic messages, cannot control a display screen, cannot implement a machine learning algorithm, nor implement a machine learning algorithm feedback loop, and the like).
In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art will now appreciate that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art. Furthermore, references to specific percentages should be construed as being “about” the specified percentage.
A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.
Moreover, embodiments can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Any suitable computer-usable or computer readable medium may be utilized. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and integrated circuits (ICs) with minimal experimentation. For example, computer program code for carrying out operations of various example embodiments may be written in an object oriented programming language such as Java, Smalltalk, C++, Python, or the like. However, the computer program code for carrying out operations of various example embodiments may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or server or entirely on the remote computer or server. In the latter scenario, the remote computer or server may be connected to the computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
This application claims the benefit of U.S. Provisional Patent Application No. 63/390,802, filed Jul. 20, 2022, entitled “FEEDBACK APPARATUS AND METHOD FOR DYNAMIC CONTROL OF AN E-COMMERCE PLATFORM”; the entire contents of which are incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
8255524 | Devitt | Aug 2012 | B2 |
9999805 | Ahuja | Jun 2018 | B2 |
10135287 | Yuasa | Nov 2018 | B2 |
10938661 | Pignataro | Mar 2021 | B1 |
10949788 | Wilson | Mar 2021 | B2 |
11809267 | Gusat | Nov 2023 | B2 |
20090281845 | Fukuda et al. | Nov 2009 | A1 |
20100077077 | Devitt | Mar 2010 | A1 |
20140157142 | Heinrich | Jun 2014 | A1 |
20160103918 | Alekseyev et al. | Apr 2016 | A1 |
20200236562 | Soundrarajan | Jul 2020 | A1 |
Number | Date | Country |
---|---|---|
WO-2021222384 | Nov 2021 | WO |
Entry |
---|
Hesse et al., “Visualizing time-dependent key performance indicator in a graph-based analysis”, Proceedings of the 2014 IEEE Emerging Technology and Factory Automation, Sep. 1, 2014. |
Abe et al, “Analyzing Business Processes by Automatically Detecting KPI Thresholds”, IEEE International Conference on Services Computing, Jun. 1, 2016. |
Unilytics Corporation, Unilytics simplifies the understanding, calculation and measuring of Key Performance Indicators (KPIs), unilytics.com, Nov. 2, 2010. |
Unilytics Corporation, “KPI Karta”, brochure, date unknown, unilytics.com. |
Enhorning, Peder, “Digital Analytics Reporting Services Proposal”, version 1.0, Jan. 17, 2017, Unilytics Corporation. |
Unilytics, “Business Intelligence & Analytics Solutions”, brochure, date unknown, unilytics.com. |
Unilytics Corporation, “KPI Karta—Actionable Key Performance Indicators”, 2014, unilytics.com, URL: http://unilytics.com:80/services-2/kpi-karta, Retrieved from The Wayback Machine at URL: https://web.archive.org/web/20140804122922/http:/unilytics.com/services-2/kpi-karta on Oct. 18, 2023. |
Unilytics, “KPI-Karta”, Jun. 1, 2016, unilytics.com, Retrieved from the Internet on Nov. 3, 2023 from URL: https://unilytics.com/dont-visualize-what-you-cant-see/kpi-karta/. |
Number | Date | Country | |
---|---|---|---|
20240031251 A1 | Jan 2024 | US |
Number | Date | Country | |
---|---|---|---|
63390802 | Jul 2022 | US |