The Purpose of Offerbots

[This article is currently being written – 28 May 2020]

Offerbots are intended to solve the problem. That is, their purpose to shift us from:

  1. the existing attention economy (in which aggregators give us ‘free’ external offer processing to capture our attention, direct it toward advertising and take our money, efficiency and opportunities), to
  2. an information economy (in which we pay for our own external offer processing in order to control which offers our attention is allocated to).

The greatest risk in the offerbots project is that we’ll deliver an oversimplified or incomplete offerbot. Doing so might give the appearance of solving the problem without actually addressing it. What this article seeks to do, therefore, is explain the tasks that offerbots must perform at a high level. They are:

  1. describing offers of any kind,
  2. sharing offers with anyone,
  3. creating feedback loops,
  4. processing offers in any way,
  5. representing offers in any medium, and
  6. doing all of the above at reasonable scale.

Describing offers of any kind

Offerbots are intended to describe and represent offers of any kind. That is, they must:

  1. increase the breadth or range of offers which can be made (to cover and extend the scope of our economy, society and information), but also
  2. improve our capacity to distinguish between offers (to create a multitude of new niches between existing opportunities).

The first thing offerbots must do, then, is uncompress our offers. As human attention became increasingly scarce, ads went from this:

to this:

We might laugh at the ad at the top, but that detail is important (and is only scratching the surface of the product’s attributes).

The Apple ad, by comparison, tells you nothing about the product except that owning one will allow you to ‘think different’ as famous thinkers in history did (without an Apple computer). Certainly, Apple’s ad conveys a great deal of intangible information – an advertisement of this quality and originality is a signal that the computer will be similarly impressive. Given that the campaign was created by someone at an advertising agency, however, it’s easy to imagine an alternate history in which IBM used that agency instead of Apple (and Einstein promoting ‘Think IBM’ instead).

My point is that our offer-making process has become completely disconnected from the products and services that we are being offered. Because we cannot compare a set of products, we’re susceptible to the use of stories and emotion to draw us to a single product (without comparison to competitors). That’s ideal for the advertising vendor (and advertising agencies) but bad for the rest of us. It’s created a strange economy in which it’s not sufficient to be an efficient producer of high quality goods – vendors must either:

  1. create products which are so different that they’re remarkable (are spread by word of mouth because they’re worth telling others about), or
  2. become (or hire) incredible story tellers in order to ‘cut through’ the noise in their marketing.

To fix this, we can use the That’s not to say that story telling and emotion is unimportant. Our offers must contain story-telling components, with links to video, image and audio files which convey those stories. But they must also contain rich detail so that buyers can use their offerbots to:

  1. specify minimum standards to filter out offers which do not meet their needs,
  2. compare the remaining offers to identify a set of products (any of which would meet their needs), and then
  3. consider the stories for any of those remaining offers to choose one which they prefer.

Doing this will Because of the scarcity of human attention, we currently have these in the wrong order, giving economic power to story tellers rather than to great producers.

It’s critical, therefore, that offerbots enable producers to simply produce and describe what they produce in an offer.

Differentiation is still important, but the threshold for that differentiation needs to be greatly reduced from being remarkable (being so significantly different that it is worth remarking about to another person) to simply being different in a way which is meaningful to some buyers (e.g. offering a television with one more HDMI port than your competitors).

Story telling is still important, but it needs to demoted to a secondary role.[1]

[Content below this line is currently being written and edited – 22 May 2020]

Sharing offers with anyone

Offerbots allow offers to be freely shared. The offer may be created by a person, organization, device or process and received by any person, organization, device or process.

making the offer and whoever they would like to receive the offer.

This is currently restricted by the use of human attention as the medium for offers.

The relative abundance of affordable computing power will increase the number of offers which can be made, received and automatically pre-processed by offerbots. It’s worth noting, however, that computing power is still scarce and, in particular, that wealthy people have greater access to computing power than poor people, limiting their reach.

[Offers for offers. Decentralized]

This might be individuals, groups of people (friends, colleagues, customers, etc.) or the wider public.

It is clear, then, that the offerbot must represent the owner’s social graph for this to happen. The social graph must not be owned by a corporation but by the individual themselves.

This is currently constrained by the use of human attention as the primary medium for sharing offers and, therefore, being constrained by its scarcity.

Without attention barriers.

Social graph must be owned by the individual, not an aggregator.

Receiving is not compulsory. The recipient must decide. But feedback loops require the message. SMSes are sent because they are always received.

Receiving offers

Creating feedback loops

Offers will be constructed with Linked Data. This is data which is designed for machines to read and use by:

  1. expressing and gathering it via the web, and
  2. using public and shared definitions for concepts which are identified by a ‘link’ (a URI).

To date linked data has been used primarily with schemas (such as the schema for a product on schema.org). These schemas are designed primarily with aggregators in mind, giving vendors information on how they can describe their products such that aggregators

This means that they are designed with a particular form of tension. If the schema requires too much data from vendors, they will reject the specification and it will not be adopted. If the schema requires too little data from vendors, the schema will be adopted but will not be useful to aggregators and their users.

The missing component in this schema design quandary is a feedback loop between vendors and buyers. When a schema is designed by or for an aggregator, the aggregator can only guess what information is required and will, invariably, select only the short head of data (which they guess many people will want) rather than the long tail of data (which would describe the intricate differences between offers such that buyers can determine between them). This is, once again, another form of offer compression and homogeneity in our markets (and a missed opportunity for linked data).

With a feedback loop between vendors and buyers (with no aggregator mediating and commodifying their communications), vendors can start an offer with what they believe buyers want to know and then buyers can indicate what they actually want to know by using their offerbot to:

  1. ask questions of many vendors through their offerbots (such that the vendor will embed the answering data in their offer, making it richer and more complete), and
  2. request offers which match specific filters, each of which contains information about the buyers specific preferences. For instance, a buyer might be looking for a television with 3+ HDMI inputs, which indicates that the offer should contain information on the number of HDMI ports for each television.

The presence of a feedback loop does negate the need for a schema for offerbots. It means that the offerbot schema should instead:

  1. define the minimum set of data needed to describe an offer in a uniform manner, but
  2. maximize the diversity of products, services, information and other goods which can be described in those offers.

Processing offers in any way

Filters

Algorithms (heuristics)

It is not enough to merely distribute offer processing – offerbots must also be able to support and represent the diverse goals and preferences of billions of people (as explained by Friedrich A. Hayek, where offerbots will aid the price system by describing what is being priced).

Building trust

Representing offers in any medium

Diversity in our offers and the way we process them. Filters, algorithms, generation of maps.

Vendor / buyer roles are compressed by the fungibility, efficiency and dominance of money (due to high matching costs ). Also hidden things are transacted – data.

Google has reduced information to facts.

No one can comment.

Alternate facts, COVID-19. Big issues, we can’t get them right. Filter bubbles.

‘Consumer’

Economic, Social and Informational

Peers, not consumers.

At reasonable scale


Footnotes

  1. It’s worth noting, of course, that advertising is a costly signal which engenders trust in users, and that advertising frequently makes the information more believable through the availability heuristic. Put another way, offerbots may allow you to compare Apple computers to Orange computers, but if you’ve never heard of Orange computers you’re unlikely to trust and purchase from them. We’ll discuss this issue of trust in the article on project challenges.