Expanding on 'How it works?' - an explanation of how Online Shop uses Artificial Intelligence and Machine Learning

A deeper dive into the engine we are developing at Online Shop, and a small showcase of it's current capabilities and inner workings.

Expanding on 'How it works?' - an explanation of how Online Shop uses Artificial Intelligence and Machine Learning
Cover art provided by Mykola Holyutyak

A deeper dive into the engine we are developing at Online Shop, and a small showcase of it's current capabilities and inner workings.

With my previous article, titled 'Achieving technological singularity via Artificial Intelligence and Machine Learning - The vision for Online Shop', I received a lot of questions on how our 'engine' exactly works, perhaps my attempts to oversimplify have left a lot of people wondering on what exactly happens for us to make such optimizations.

As someone who believes that 'sharing is caring', especially when it comes to technological advancements, I will aim to simplify and deduce some of the inner workings of our engine and how it works. Most of what we have built is completely proprietary, we do not solely rely on existing learning models or resources, besides the raw computational power required to run the engine and several open source libraries from OpenAI, to assist with our own developments in language learning - is our own. I believe that in good time, after realizing this vision for e-commerce, we can start releasing our own instances for the public to fork and initiliaze within their own projects, independent of Online Shop.

The current model we all use

Using current tools and practices, human input is always required to create web pages. There are tools and services that try to ease this process, however, most introduce an abundance of options that quickly complicate things.

Whether you're building a blog hosted on WordPress, or using the likes of Webflow, you'll always need some human input. And, even for our own engine, this is also necessary - at least, in the beginning.

The first drafts of any property are based on preconceived notions of what the user experience should be like, based on technical limitations, budget, design briefs or what looks good/works for others. Whilst example-a.com might work and look good for their own customers, a competitor drawing inspiration for their own website, example-b.com, might find themselves wasting valuable resources and time, only to experience disappointment. What works for example-a.com will not work for example-b.com.

This approach will always be flawed as it requires enormous investment of time, capital and resource. No matter how much A/B testing is done, you can only appeal to so many of your users. Progressive steps are taken to improve and evolve for the benefit of their users by those who have the time, resource and capital required to conduct such A/B tests, placements, fonts, graphics, and so on. One must also take into account their landing page quality to reduce bids on ads should they wish to run ad campaigns online, improve readability for greater visibility across search engines, remove unnecessary and deprecated code which only increases load times - for most use cases, unless you have built it yourself, or have a team in-house, you will not be able to do so without major changes to the overall property you are trying to optimize, update or refactor.

And for those truly nihilistic, or adventurous that choose to do it themselves via self-hosting, things such as load balancing, DDoS mitigation, introduction of CDN’s and other such measures to ensure quality, safety and overall longevity become part of everyday 'to do' lists.

How our engine works

In this, I will use a small example of how our engine, which I previously defined for simplicity as a combination of Artificial Intelligence, Machine Learning, Computer Vision, proprietary algorithms, event and data capture among other things necessary for it to work, learns, adapts, optimizes and changes elements of a web property, both in real time and through a schedule that is similar to running a cron job on a server.

We use this to create clear heatmaps with assigned scores for every element of the web property. Of course our engine does not need the visual output of a heatmap, we use it to aid in our research, development and optimization of it's success and failure. All of this creates an overall clarity score, based on what a human eye would focus on.

Due to the abundance of various devices, screen resolutions, browsers, operating systems, color profiles and so forth in real life scenarios we are only able to process a dozen or so most popular ‘instances’ that most would use.

To put it in example; for testing purposes we created an environment and selected a sample of users that use a Macbook Pro with latest version of Safari, all share the same color profile and screen size for our engine to capture data from. In a live environment, such data is collated into sets with the most prominent receiving priority to analyze, change and optimize. Due to computational limits at this stage, we prioritze and collate this data e.g. a shop that sells art supplies and receives traffic from users (buyers) use the same device such as a Macbook Pro with latest Safari for Desktop and those using mobile devices, are using an iPhone Pro Max for Mobile. Half a dozen users who are running uBuntu on various machines for Desktop and various Android models for Mobile, at this moment would not be taken into account and optimized for as not enough data exists and the amount of additional power required adds unnecessary strain and provides inconsistencies.

This is one of the biggest challenges for our engine.

The engine then attempts to create a focal focus point across the entirety of the web property - mimicking what a human would focus on when viewing what is being displayed. For example, for pages that are showcasing products at a category level and then on individual level, these are clustered as a group. Every product category display is optimized as one, same with individual product showcase pages.

The engine captures every element, class and piece of a web property, even those that were invisible to the human eye, such as the brand logos in the section below. This also includes capture of where tracking pixels are, such as the header.

For simplicity, we can see the changes made to the logo within the header to go from this:

To this:

With the width, height, alignment changed and the ability to go back to the home page of the web property assigned.

Now with hundreds of such small and big adjustments and optimizations based on data that our engine captures and learns from, we have a completely new look:

Such changes made based on the captured as explained in the previous article, produces a completely new experience geared for the best user experience possible, reducing if not eliminating, the need for human input, which will always produce errors and flaws. From simple changes such as positioning of a logo, to text that is dynamic and geared towards buyer affinity, generated completely by our engine.

At this stage this means a unique experience for a set of buyers, and increased conversions for sellers.