Project group personalisation of internet-based retail scenarios

Project group personalisation of internet-based retail scenarios

The aim of this project group is to design and implement a system that maps personalised, internet-based retail scenarios

Situation

Let us imagine that we are a card provider (analogue to Payback, Miles&More) or similar. We want to realise a new scenario for the use of customer cards that are used by several retailers in order to later "sell" them to a retailer.

Card systems

Card systems offer advantages for retailers, card system providers and customers. Customers have the opportunity to make use of a personalised range of information and goods. This is made possible by the fact that commercial transactions of participating customers are transmitted by the merchants to the corresponding card provider. In return, the merchant receives a fee from the card provider. The card provider then analyses the customer data. Today, the analyses carried out by the card providers are limited to segmenting customers into customer groups (e.g. Amazon). Merchants endeavour to make their customers the best possible offer. They can do this today by purchasing analysis results from card providers in the form of customer group descriptions and customer group descriptions. This can be done using a publish/subscribe approach, for example. The retailer can now use this purchased information to provide customers with customer group-centred offers, e.g. via the Internet.

This has advantages for all participating groups: the customers receive a customised range of information and goods, the retailer can better retain its customers ("transparent customers") and the card provider earns money by selling its analysis results. As a rule, however, it is the card provider and the retailer who really earn, as customers provide their data for a small fee. A further disadvantage for the customer is that he may not be able to keep any secrets from his merchant. The merchant, on the other hand, becomes dependent on the card provider cooperating with him by introducing card systems. It can also be a disadvantage for customers and merchants that their data is now stored in an information network over which they have only limited influence. If, for example, a card provider in a sector cooperates with a merchant, it should be prevented (even technically) from passing this data on to a competitor of this merchant. There are actually no disadvantages for the card provider. For this reason, we want to put ourselves in the role of a card provider.

A trading scenario, as we want to look at it, can be seen here.

In order to be able to develop a system that is offered by a card provider, it is necessary to consider both the side of the card provider and the role of the merchant. For this reason, let's take a closer look at these roles:

Merchant

In the architecture we are looking at, a merchant participates in two forms of commercial relationships. On the one hand, he trades with customers by selling goods. On the other hand, he sells information to the map provider and buys analysis results from the latter. He collects and stores all data (sales data, prospective customers, web logs, etc.) relating to his business. A small part of this data (the data relating to the card offered, usually the information on the receipt) is transferred to the card provider. However, he has far more information at his disposal that he could use to individualise his offer. In doing so, he could draw on some of the analysis results supplied by the card provider. If he knows the preferences of his customer as an individual (corner shop metaphor), he can, for example, make a personalised presentation of his goods in an electronic shop system.

Card provider

The retailer enters into trading scenarios with retailers and end customers. In order to obtain the data needed to identify customer groups, card providers 'pay' customers in the form of rewards. Card providers ?pay? customers in the form of rewards (points systems, bonuses, etc.). The card providers obtain the customer data from the merchants, who receive a fee (e.g. in the form of analysis results) for processing the data. The card provider collects the data, integrates and cleanses it and stores it permanently. Using this processed data, the card provider is able to carry out various types of analyses, including shopping basket analysis, customer grouping, concept description and the derivation of rules. An example of such a rule (fictitious!?): "A young father in his late 20s who buys Pampers in a supermarket has an x% probability of also buying a 6-pack of beer." He can now offer the results of these analyses to retailers. The people involved in this trade may be different from those who participated in the data delivery.

Objectives of the project group

The tasks of the project group are divided into two areas:

  • Derivation of personalised data
    • Customer segmentation: How can I use (integrated) customer data from several retailers to categorise customers into groups? (card provider)
    • Individualisation: How can I create individual, interesting offers for the customer from the data? (Merchant)
  • Internet-based, individualised presentation of data
    • How can retailers make personalised offers? The customer should receive personalised offers.
    • We want to design and realise a shop system for a retailer as an example.

What do we offer?

Fun, exciting topics and working with the latest technologies.

Organiser

Appearance (minimum results)

  • Active participation in the analysis, conception and implementation
  • Fulfilment of assigned tasks
  • Presentation and preparation of seminar presentations
  • Preparation of interim and final reports as well as any necessary documentation

Hardware

  • SUN workstations
  • DEC workstations
  • PCs under WindowsNT and Windows 2000

Software

  • Netscape Navigator
  • Microsoft Explorer
  • Java Developers Kit 1.3 (JDK)
  • Bean Developers Kit (BDK)
  • JBuilder 4 or JDeveloper 9i
  • Oracle 9i, Oracle 9i Application Server
  • CVS (version control)
  • Rational Rose (UML)
  • Perl (for the realisation of CGI scripts, if necessary)
  • LaTeX (for documentation)

Project website

(Changed: 11 Feb 2026)  Kurz-URL:Shortlink: https://uol.de/p33507en
Zum Seitananfang scrollen Scroll to the top of the page

This page contains automatically translated content.