Data analyse rapport Crunch Analytics

Dit rapport van Crunch Analytics beschrijft hoe ze aan de slag zijn gegaan met de positie data van de bezoeker en de object data om interesseprofielen te genereren via een recommendation engine.

1. Executive summary

Tijdens dit onderzoeksproject binnen het Design Museum Gent is Crunch Analytics aan de slag gegaan met positie-data gecapteerd via de ultra-wideband technologie van Pozyx om op die manier de positie van bezoekers te koppelen aan hun interactie met de tentoonstelling.

De opdracht was drieledig:

de connectie voorzien tussen verschillende databases,
het verwerken van de ruwe data tot bruikbare inzichten voor bezoekers en curatoren
door middel van algoritmes,
Het doorsturen van de verwerkte data en inzichten naar een gebruikersinterface
(tablet aanwezig in het museum) en dashboard.

De belangrijkste lessen die we hebben kunnen trekken uit dit onderzoeksproject zijn de volgende:

De kwaliteit van data is essentieel om kwalitatieve aanbevelingen te kunnen doen. Dataverrijking en unificatie over verschillende databronnen binnen en buiten de stadsdiensten zou hoog op de agenda moeten staan.
De locatie in combinatie met de technologie heeft bepaalde limitaties. Vele diverse objecten dicht bij elkaar maakt het moeilijk om 1 positie uniek te karakteriseren.

2. Inleiding

Crunch Analytics werd geselecteerd als partner in het MoTfP-project om het data-luik voor zijn rekening te nemen. Het was onze doelstelling om de data die gecapteerd werd door de hardware van Pozyx om te zetten in bruikbare inzichten voor het Design Museum Gent.

Deze inzichten hebben een dubbel doel:

Enerzijds inzicht verschaffen aan de interne medewerkers van het museum, door
middel van een dashboard.
Anderzijds inzicht verschaffen aan de eindgebruiker, de museumbezoeker.

Hieronder volgt een overzicht van de analyses en inzichten die bij aanvang van het project zijn geïdentificeerd als relevant door de verschillende stakeholders in het project.

2.1 Analyse van het bezoek

Tijdsduur van een bezoek: meegenomen in project scope.
Afstand afgelegd: meegenomen in project scope.
Route (heatmap) afgelegd: meegenomen in project scope.

2.2 Filters en contextuele parameters

Groepen vs. individuen: niet in project scope omwille van het huidige opzet. Er zijn slechts 25 tags in omloop, waardoor we niet altijd een volledige groep kunnen volgen indien er al tags in gebruik zijn.
Dagen & tijdstippen: meegenomen in project scope.
Vakantieperiodes: niet in project scope, externe databron integreren.
Weer: niet in project scope, externe databron integreren.
Met of zonder boekje: meegenomen in project scope.
Leeftijdscategorie: meegenomen in project scope.
Postcode (toerist / niet): niet in project scope, aangezien de gebruikersinterface in de
eerste versie niet meertalig is.

2.3 Interactie met de tentoonstelling

Interactie met de objecten: er is een selectie gemaakt van 25 objecten op het verdiep Object Stories. Niet alleen de tijd- en budget limitaties van dit onderzoeksproject, maar ook de technische haalbaarheid hebben geleid tot het maken van een selectie. Om de locatie van een persoon (gemeten door de positie van de tags ten opzichte van de anchors) te bepalen ten opzichte van de positie van de objecten (de positie van de objecten op een plattegrond), moeten de persoon-coördinaten uitgezet worden op de plattegrond. Na het uitvoeren van een plaatsbezoek in het museum en onderzoek naar de limitaties van de technologie, was gebleken dat het enkel mogelijk was om vrijstaande objecten te selecteren. Objecten die dicht bij elkaar staan, boven of achter elkaar staan zijn zeer moeilijk te isoleren. Een kanttekening bij deze metriek is dat we de assumptie nemen dat de bezoeker ook kijkt naar het object waar hij/zij het dichtst bij stilstaat.
Interactie thematische routes: er zijn 5 thematische routes op het verdiep Object Stories. Om interactie met de routes te meten, hebben we elke route met een tag gelopen om de positiedata te capteren en zijn we blijven stilstaan bij de geselecteerde objecten op die route.
Interactie typologische opstelling vs. artistieke installatie: niet in project scope.
Interactie informatiebordjes: de interactie met informatiebordjes is mee opgenomen door de coördinaten te bepalen per bordje. Dit door met een tracker gedurende een
aantal minuten stil te staan per bordje.
Interactie met beeldmateriaal "Object Interviews": niet in project scope omwille van tijd limitaties.

2.4 Bezoekersprofielen definiëren

Interesseprofiel definiëren: meegenomen in project scope, door de combinatie te maken van de positiedata van bezoekers, de positiedata van objecten en de objectinformatie uit Adlib kon er een interesseprofiel van de bezoeker opgemaakt worden. Afhankelijk van de lengte waarbij een bezoeker stilstond bij objecten, kon zijn/haar interesse in bepaalde periodes, stromingen en kunstenaars over het gehele bezoek worden afgeleid.
Gedragsgebaseerde bezoekersprofielen (supervised): naast interactie met objecten, kon er ook een profilering toegepast worden op de manier waarop bezoekers zich voortbewegen in het museum. Hiervoor hebben we gebruik gemaakt van de supervised learning methode, waarbij er op voorhand bepaalde profielen worden bepaald waarna personen aan een dergelijk profiel kunnen worden toegekend (= supervised learning). Hiervoor werden de profielen van Zancanaro et al. gebruikt:
- Mier: Volgt een welbepaald pad en spendeert veel tijd bij elke opstelling.
- Vis: Spendeert het meeste van zijn tijd in het centrum van de ruimte en gaat
  zich niet op een enkele expositie fixeren.
- Vlinder: Volgt geen specifiek pad maar stopt bij quasi willekeurige werken.
- Sprinkhaan: Bezoeker met voorkeuren voor zeer specifieke werken, negeert
  alle andere werken.
Gedragsgebaseerde bezoekersprofielen (unsupervised): niet in project scope.
Gedragsanalyse bezoekersgroepen (supervised): analyse van groepen werd niet meegenomen in de project scope.
Gedragsanalyse bezoekersgroepen (unsupervised): analyse van groepen werd niet meegenomen in de project scope.

2.5 Aanbevelingen & toeleiding

Thematische routes linken aan aanbevelingen: niet de routes, maar geselecteerde objecten zijn gelinkt aan vaste gecureerde aanbevelingen. Per object is zijn er 1 à 2 aanbevelingen en toeleidingen naar plaatsen in de Gentse stad voorzien door de curatoren van Design Museum Gent.
Interesseprofiel linken aan andere musea: de mogelijkheden zijn onderzocht, maar er was te weinig metadata die kon gelinkt worden tussen de verschillende musea.
Interesseprofiel linken aan events: de mogelijkheden zijn onderzocht, maar er was te weinig metadata die kon gelinkt worden tussen de UitInVlaanderen database en onze data.
Interesseprofiel linken aan boeken: de interesseprofielen worden gelinkt aan relevante boeken in de BibNet database.
Interesseprofiel linken aan onroerend erfgoed: de mogelijkheden zijn onderzocht, maar er was te weinig metadata die kon gelinkt worden tussen de Erfgoed database en onze data.

3. Het proces

Er zijn 3 grote stappen in het proces:

Data extractie: positiedata van de Pozyx server.
Data verwerking: verwerken van de positie-data (cleaning en transformatie), algoritmes en berekeningen op basis van de data om de verschillende profielen te berekenen en matching met data voor aanbevelingen.
Inzichten weergeven: in enerzijds het dashboard voor curatoren en anderzijds de gebruikersinterface.

4. De server

Volgende figuur geeft een overzicht van de gebruikte data-infrastructuur. De Google Compute Engine is de belangrijkste component van alle Crunch componenten, voor specificaties zie sectie 1.1. Deze server zal communiceren met

de POZYX server en de positie-data opvragen, zie sectie 5
de user interface om gebruikers inzicht te laten hebben in hun museumbezoek, zie
sectie 6
Google BigQuery en het PowerBI Dashboard om de curatoren een inzicht te laten
hebben in de gedane museumbezoeken, zie sectie 7.

Als Crunch server is er gekozen voor een Google Compute Engine. De standaard machine (n1-standard-1) met 1 CPU en 3.75 GB voldoet voldoende in de nodige vereisten (https://cloud.google.com/compute/all-pricing?hl=nl).

Merk op dat deze server vervangen kan worden door een gelijkaardige technologie zoals een Microsoft Azure Virtual Server, Amazon Web Services, of een lokale server geconnecteerd met het internet.

5. Data verwerking

Een belangrijke taak van de Google Compute Engine is om de positionering data van POZYX op te halen, zie sectie 5.1. Nuttige informatie zoals favoriete objecten van een bezoeker moeten uit deze data gehaald worden, zie sectie 5.2. Op basis van deze informatie worden bezoeker specifieke aanbevelingen gedaan, zie sectie 5.3.

5.1 Positionering data

De positionering data van POZYX is opgeslagen in een InfluxDB, een database die in staat is om tijdreeksen op een efficiënte manier op te slaan en te bevragen. Crunch zal deze databank aanspreken door gebruik te maken van een API call. In Python zit dit er als volgt uit:

De verkregen positionering data van Pozyx heeft de volgende eigenschappen:

time,
anchor_amount
blink_index
coordinates_x
coordinates_y
coordinates_z
latency
rate_packet_loss
rate_success
rate_update
success
tag_id

Een aantal keer per seconden worden al deze eigenschappen per tag gecapteerd. Een voorbeeld van de data wordt hieronder gegeven:

Alleen de meetpunten waarvan success gelijk is aan True en de rate_success / rate_update groter is dan 0.5 worden geselecteerd. Dit om te vermijden dat onzekere en misschien foutieve data-punten mee in rekening genomen zouden worden. Voor de verdere analyse worden time, coordinates_x, en coordinates_y gebruikt. De waarde coordinates_z is afgesteld door POZYX om altijd dezelfde waarde te hebben (= 1000). Tags die niet op de eerste verdieping van het Design Museum actief zijn, zullen niets versturen.

Voor de verdere analyse is het noodzakelijk om de data van 1 gebruiker uit deze dataset te halen en niet de data van 1 tag, want 1 tag kan door meerdere gebruikers op verschillende tijdstippen, zie onderstaande figuur. Om dit te bereiken, moeten we per tag bijhouden wat het laatste gebruik ervan is. Als een nieuwe bezoeker zijn data wenst te krijgen, wordt de data sinds het laatste gebruik genomen en wordt het laatste gebruik gereset naar het tijdstip van vandaag.

De data per gebruiker kan geplot worden door gebruik te maken van de coordinates_x, en coordinates_y. Hiervoor is een transformatie nodig. Als we volgende plattegrond in acht nemen:

dan is de vereiste transformatie nodig:

x_oorsprong = 657 y_oorsprong = 80 lengte = 48 hoogte = 38 lengte_fig = img.shape[1] breedte_fig = img.shape[0] new_coordinates_x = x_oorsprong + (lengte_fig / lengte ) * (coordinates_x /1000) new_coordinates_y = y_oorsprong - (breedte_fig / hoogte ) * (coordinates_y/1000))

Als de nieuwe coördinaten geplot worden, dan wordt dit bijvoorbeeld:

Merk op dat deze transformatie anders is voor andere afbeeldingen van de plattegrond. Uit deze data per bezoeker zijn volgende kenmerken makkelijk te berekenen:

de doorgebrachte tijd in de Object Stories collectie: per bezoeker is het eerste en het laatste meetpunt gekend. Deze meetpunten hebben een tijdstip waardoor het tijdsverschil berekend kan worden.
de afgelegde afstand in de Object Stories collectie: per bezoeker zijn er meetpunten die een x en y coördinaat voorstellen. Deze punten worden geordend op basis van hun tijdsaanduiding. Daarna worden tussen twee opeenvolgende punten de afstand berekend. Deze individuele afstanden worden opgesomd.

5.2 Data Analyse

Deze bezoekersdata kan nog verrijkt worden, bijvoorbeeld door de plaatsen te detecteren waar ze stil staan (sectie 5.2.1) en deze te benoemen (sectie 5.2.2). Op basis van deze benoemde clusters, kan er extra informatie gehaald worden, zoals favoriet object (sectie 5.2.3).

5.2.1 Clustering

De data per bezoeker wordt geleverd als een tijdreeks. Uit deze tijdreeks moeten we zien te achterhalen waar een bezoeker is blijven stilstaan. Als een bezoeker blijft stil staan, dan zullen x en y coördinaten voor opeenvolgende tijdstappen heel gelijkaardig zijn. Ze vormen groepen, posities.

Om deze groepen op een automatisch manier te extraheren gebruiken we een clustering-algoritme. Aangezien er niet geweten is hoeveel groepen er zijn (bezoekers staan op verschillende en verschillend aantal posities stil), wordt het DBSCAN algoritme gebruikt. Bij dit algoritme zijn er twee parameters:

1. Epsilon, deze is ingesteld op 100 wat wil zeggen dat de coördinaten in een groep niet verder 100 van elkaar mogen liggen. Volgende plot toont twee punten die op 100 van elkaar liggen:

2. Minimum aantal punten, deze is ingesteld op 10 wat wil zeggen dat er pas sprake is van een groep als er minstens 10 coördinaten dicht bij elkaar liggen. Dit betekent dus dat er minstens 2 seconden stil gestaan moet blijven worden op ongeveer dezelfde plaats.

Aangezien elk meetpunt ook een tijdswaarde heeft, kan de doorgebrachte tijd in een groep (op een positie) berekend worden. Door het verschil te berekenen van de begin- en eindtijd. Nu is er geweten op welke coördinaten de bezoeker is blijven stilstaan en hoelang, maar nog niet wat er op deze plaats staat. Volgende sectie legt uit hoe deze informatie verkregen is.

5.2.2 Labelen van alle mogelijke clusters

De dataset die de coördinaten verbindt met de aanwezige objecten op de verdieping van Object Stories moest bij het begin van het project nog gecreëerd worden.

Het principe om deze dataset te creëren is simpel:

een persoon gaat met een tag op een positie staan,
de coördinaten worden uitgelezen,
deze coördinaten worden gelabeld met het object dat je kan zien op deze positie.

Op de posities waar je maar 1 object ziet, is deze aanpak heel makkelijk. Bijvoorbeeld op de plek waar je dit ziet:

Maar het Design Museum is geen klassiek museum en op veel plaatsen zie meerdere objecten tegelijkertijd:

Deze plaats samenvatten in 1 label is onmogelijk door twee redenen: 1. het is onmogelijk om te weten waar de bezoeker precies naar het kijken is,

2. al deze objecten hebben een verschillende labels. Ze zijn gemaakt door verschillende artiesten, in verschillende tijdsperioden, ...

Sommige plaatsen hebben we niet kunnen voorzien van een label, zoals de stoelen en de keramiek in de wandkasten. Bij deze laatste was het namelijk onmogelijk om te weten naar welke hoogte de bezoeker aan het kijken was.

Op andere plekken is het bovenstaande probleem deels aanwezig, maar is er vanuit gegaan dat bepaalde objecten zeker enige aandacht van de bezoeker gekregen hebben. Bijvoorbeeld in de volgende figuur gaan we er vanuit de de persoon zeker de kaptafel gezien heeft en zal de locatie het label van de kaptafel krijgen. Dit terwijl er eigenlijk meer te zien is, zoals het vosje.

De posities die objecten voorstellen krijgen de volgende labels mee:

● Naam object ● Stijlperiode ● Artiest

Naast posities die de objecten voorstellen, zijn er ook posities die gelabeld worden als de informatieborden en de zuilen met de informatieboekjes. Deze krijgen respectievelijk het label informatiebord en zuil met een nummer.

In totaal zijn er 25 objecten, 31 informatieborden en 5 zuilen.

Nu is er geweten op welke coördinaten de bezoeker is blijven stilstaan, voor hoelang, en naar welke objecten er gekeken is.

5.2.3 Informatie uit clusters

Volgende informatie wordt geëxtraheerd uit de bovenvermelde gegevens, bij deze oplijsting wordt er vanuit gegaan de bezoeker is blijven stilstaan op posities waar we labels voor hebben:

Het favoriet object: dit is de positie waarbij de bezoeker het langst is blijven stil staan en waarvan we label hebben. Het kan dus perfect mogelijk zijn dat de bezoeker het langst is blijven stilstaan bij een positie dat geen label heeft. Indien dit het geval is, wordt er gekeken of de tweede langst bezochte positie, een label heeft. Zo worden alle posities overlopen (in volgorde van langst blijven stil staan naar minst langst blijven stil staan) tot er labels verkregen is.
Het favoriete object is het object waarbij het langst is blijven stil staan. Lang blijven stilstaan omdat je er iets lelijks wordt gezien of omdat er daar een praatje gemaakt is, kan niet worden gedetecteerd.
Een voorkeur voor stijlperiode: bij elke positie is er geweten hoe lang de gebruiker er is blijven stil staan en welke stijlperiode het bekeken object heeft. Dezelfde stijlperiode kan meerdere keren voorkomen (twee locaties met dezelfde stijlperiode). Voor deze stijlperioden worden de verschillende tijden met elkaar opgeteld meerdere malen voorkomt, worden de geregistreerde tijden met elkaar opgeteld. De stijlperiode waarbij het langst is blijven stilstaan, heeft de voorkeur van de bezoeker.
Het gebruik van de boekjes: in een aparte gang op de verdieping van de object stories, staan er 5 zuilen met elk informatie en bijbehorende route-boekjes die door de bezoeker genomen kunnen worden. Uit de clusters kan er gedetecteerd worden bij welke zuil de bezoeker is blijven stil staan. Hieruit concluderen dat een bezoeker een bepaalde route gevolgd heeft, is niet mogelijk aangezien een bezoeker bij meerdere zuilen stil gestaan kan hebben.
Het volgen van een route: bij elke zuil is er een route-boekje die gevolgd kan worden. Er is een dataset opgesteld die bijhoudt welke objecten in welke route voorkomen. Indien een bezoeker meer dan 5 objecten van een route bekeken heeft, dan heeft een bezoeker deze route gevolgd. Het kan dus zijn dat een bezoeker meerdere routes gevolgd heeft.
Profilering: Er is geweten hoeveel keer de bezoeker blijft stil staan en waar dat dit is: bij objecten, informatieborden of zuilen. Uit deze informatie wordt een profiel opgesteld, zoals gedefinieerd in sectie 2.4:
1. Mier: indien het aantal locaties waar dat een bezoeker is blijven stilstaan groter is dan 20.
2. Vis: indien het aantal locaties waar dat een bezoeker is blijven stilstaan kleiner is dan 5
3. Vlinder: indien het aantal locaties waar dat een bezoeker is blijven stilstaan tussen de 5 en 20 ligt.
4. Sprinkhaan indien het aantal locaties waar dat een bezoeker is blijven stilstaan tussen de 5 en 20 ligt en de bezoeker een route gevolgd heeft.

Merk op dat het kan zijn dat een bezoeker nergens is blijven stil staan of alleen is blijven stilstaan op posities waar we geen labels van hebben. In dat geval hebben we geen gegeven om de bovenstaande informatie te berekenen en is alles onbekend.

5.3 Bezoeker Aanbevelingen

De bedoeling is om de bezoeker toe te leiden naar de stad Gent. Om deze toe te leiden wordt gebruik gemaakt van de bezoekersinformatie, zoals favoriet objecten, stijlen (zie sectie 5.2). Deze bezoekersinformatie kan vergeleken worden met andere data, zoals bijvoorbeeld evenementen, andere kunstwerken,... waarna het meest gelijkaardige evenement, kunstwerk,... wordt gegeven aan de bezoeker.

Om tot deze toeleidingen te komen wordt er gekeken naar verschillende publiek beschikbare datasets. zoals de ‘Uit in Vlaanderen’-dataset, de ‘Onroerend erfgoed’-dataset, andere museum data, en de data van de bibliotheek. Sectie 5.3.1 overloopt deze datasets met hun plus- en minpunten. Merk op dat er nog veel meer datasets beschikbaar zijn, maar deze werden of na overleg met het Design Museum niet verder onderzocht of het was al heel snel duidelijk dat er geen overeenkomstige kenmerken waren met het opgestelde profiel.

In Sectie 5.3.1 wordt besloten dat alleen de data van de bib gebruikt kan worden om een toeleiding te doen naar de bibliotheek. Sectie 5.3.2 legt uit hoe gecureerde aanbevelingen ervoor gezorgd hebben dat er toch toeleidingen naar de stad zijn kunnen gebeuren.

5.3.1 Publieke datasets

5.3.1.1 Uit In Vlaanderen

Deze dataset omvat alle evenementen, exposities,... in vlaanderen (https://www.uitinvlaanderen.be/). Om deze data op te halen bestaat er een API. Elk datapunt bestaat onder andere uit een titel, locatie, omschrijving, begindatum, einddatum en enkele labels die dit evenement beschrijven.

Uit deze API worden de evenementen gehaald die in de toekomst plaatsvinden in Gent. Volgend tabel geeft de verschillende labels weer en hun frequentie. Hierop kan je bijvoorbeeld op zien dat 92 evenementen het label ‘Tentoonstelling’ krijgen en 16 labels maar 1 of 2 keer gebruikt worden.

Er kan besloten worden dat sommige labels heel algemeen zijn (zoals tentoonstelling) en dat de iets meer gedetailleerde labels (zoals decoratieve kunst) niet vaak voorkomen.

De labels zijn echter niet gedetailleerd genoeg om het gebruikersprofiel van een bezoeker aan een evenement te koppelen. Daarom werd er besloten om deze data niet te gebruiken voor de bezoeker aanbevelingen.

5.3.1.2 Onroerend Erfgoed

De inventaris van het onroerend erfgoed biedt een overzicht van waardevol erfgoed in Vlaanderen. Zowel bouwkundig, archeologisch, landschappelijk als varend erfgoed zijn opgenomen in deze databank, goed voor meer dan 83.000 erfgoedobjecten in totaal.

De API maakt het mogelijk om alle erfgoed te selecteren die maximaal 1200 meter (in vogelvlucht) van het Design Museum liggen (coordinaten (3.720210, 51.055994)). De API call ziet er als volgt uit:

curl -X GET --header 'Accept: application/json' 'https://geo.onroerenderfgoed.be/zoekdiensten/afbakeningen?categorie=aanduidingsobjecte n&geometrie=%7B%22type%22%3A%20%22Point%22%2C%20%22coordinates%22%3A%20 %5B3.720210%2C51.055994%5D%7D&buffer=1200&geef_geometrie=0'

Er worden 3702 erfgoedobjecten terug gegeven als antwoord. Mogelijke eigenschappen van deze erfgoedobjecten zijn:

titel,
afbeelding,
beschrijving
adres
dateringen,
typologien,
stijlen,
info.

De mogelijk interessante eigenschappen die zouden overeenkomen met de bezoekersprofielen zijn dateringen en stijlen.

Een overzicht van de dateringen die meer dan 10 keer voorkomen kunnen in onderstaande tabel gevonden worden:

Volgende tabel geeft een overzicht van de aanwezige stijlen:

Tussen deze labels en hun waarden is er wel overlap met de profielen van de gebruikers: de bezochte posities hebben een datering en een stijl.

De curatoren van het Design Museum waren echter heel verbaasd om het resultaat te zien: het postmodernisme bij gevels is niet volledig hetzelfde als postmodernisme bij kunstobjecten. Daarom is er besloten geweest om ook deze dataset niet te gebruiken voor de gebruiker aanbevelingen.

5.3.1.3 Andere Museum Data

De collectiestukken van enkele musea zijn publiek beschikbaar. Zo zijn de collectie van het Museum voor Schone Kunsten Gent en het Stedelijk museum voor Actuele Kunst (S.M.A.K.) ontsloten als Linked Open Data via WikiData door PACKED.

Niet te min deze data potentieel had, werd er besloten om deze niet te gebruiken voor de bezoeker aanbevelingen. Dit omdat het de bedoeling is om de bezoekers toe te leiden naar stad Gent en niet naar andere musea. Deze data is dan ook niet in detail onderzocht.

5.3.1.4 De bib

Na aanvraag kon de API van de bib ook gebruikt worden. Met deze API kunnen we boeken zoeken met gerichte zoektermen. Daarbij kan er ook besloten worden om alleen boeken weer te geven die nog beschikbaar zijn.

Deze API is dus geschikt om boeken op te halen die gelinkt zijn aan de bezoekersprofielen. Onderzoek heeft aangetoond dat de meeste boeken te vinden zijn als er gezocht wordt met de favoriete stijl van een bezoeker. Boeken over hun favoriet object werd zelden terug

gevonden. Merk op dat zolang de zoektermen hetzelfde blijven en de collectie van de bib niet aangepast wordt, dezelfde aanbeveling gedaan zal worden.

Er werd besloten om deze dataset te gebruiken om een aanbeveling te doen op basis van de favoriete stijl. Er werd wel geopteerd om de meest geschikte boek voor te stellen zonder te kijken naar de aanwezigheid in de bibliotheek.

5.3.2 Gecureerde aanbevelingen

Aangezien er besloten is om van de publieke datasets alleen de bib-data te gebruiken, hebben de curatoren voor extra aanbevelingen gezorgd en dit op basis van het favoriet object van de bezoeker. Voor de 25 gelabelde objecten hebben de curatoren 1 tot 2 aanbevelingen gedaan. Al deze aanbevelingen leiden toe naar de stad Gent en zijn onder andere, winkels, facades, ... in de buurt.

6. De gebruikersinterface

Zie sectie 1.3.1. Initieel wordt een tag nummer door het user interface gecommuniceerd aan de Google Cloud Engine waarop de nodige informatie wordt teruggegeven. Deze wordt overlopen in sectie 1.3.2 samen met de noodzakelijk API-oproepen.

6.1 Communicatie via API

De user interface communiceert met de Google Cloud Engine via een API. Hiervoor draait op de Google Cloud Engine een service waarin een Flask applicatie draait. Deze luistert constant of de user interface een oproep gedaan heeft. Hoe de gecommuniceerde informatie verkregen wordt, is uitgelegd in sectie 2.

Belangrijk is dat deze informatie via de API oproepen enkel verkregen kan worden bij het hebben van een gebruikersnaam en paswoord. Daarenboven wordt de informatie geëncrypteerd doorgestuurd.

6.2 Specifieke API oproepen

Eerst vult de gebruiker het tag-nummer en de extra informatie in. Hiervoor krijgt deze de volgende twee schermen te zien:

De volgende API oproep wordt uitgevoerd:

curl -X POST "https://motfp.crunchanalytics.cloud/api/customer_view/" -H "accept: application/json" -H "authorization: Basic *" -H "Content-Type: application/json" -d "{ \"id\": 0, \"age\": \"46 - 55\", \"company\": \"Alleen\", \"reason_visit\": \"Object Stories\", \"tag_id\": \"2\", \"time_stamp\": \"2019-09-02T14:21:31.277Z\"}"

Als reactie krijgt de interface een bezoekersnummer. Dit bezoekersnummer is gelinkt aan het tag-nummer die zonet is ingegeven en de data die verzameld is door de gebruiker. Merk op dat het tag-nummer daarvoor perfect door iemand anders gebruikt kan worden, deze informatie zal niet gebruikt worden voor het huidige gebruik.

Vervolgt doet de API meerdere oproepen gebruik makend van het bezoekersnummer vragend naar:

Om de titel, uitvoerder van het favoriete object en de favoriete stijl te weten te komen:

curl -X GET "https://motfp.crunchanalytics.cloud/api/favo_view_text/902" -H "accept:

De 902 kan aangepast worden naar eender welk bezoekersnummer. Het antwoord:

Om de afbeelding van het favoriete object te weten te komen:

curl -X GET "https://motfp.crunchanalytics.cloud/api/favo_view_image/902" -H "accept: application/json" -H "authorization: Basic ***************"

De 902 kan aangepast worden naar eender welk bezoekersnummer. Het antwoord:

Om de tekstuele informatie van de aanbevelingen te krijgen voor een bezoeker: curl -X GET "https://motfp.crunchanalytics.cloud/api/recommendation_view_text/902"-H "accept: application/json" -H "authorization: Basic ***************"

De 902 kan aangepast worden naar eender welk bezoekersnummer. Het antwoord:

Om de figuren van de aanbevelingen te krijgen wordt de id van de aanbeveling gebruikt. Deze werd bij de vorige oproep meegegeven in het resultaat. In dit voorbeeld zijn die de ids 1509, 1510 en 1511. Volgende API call kan uitgevoerd worden:

curl -X GET "https://motfp.crunchanalytics.cloud/api/recommendation_view_image/1509" -H "accept: application/json" -H "authorization: Basic *"

Het antwoord:

De antwoorden van de API worden in het volgende scherm afgebeeld:

Bij dit scherm heeft de gebruiker de mogelijkheid om aan te duiden of hij een aanbeveling leuk vond of niet. Volgende API calls worden uitgevoerd bij het respectievelijk klikken van de duim omhoog of omlaag:

curl -X POST "https://motfp.crunchanalytics.cloud/api/recommendation_view_text/" -H "accept: application/json" -H "authorization: Basic ***************" -H "Content-Type: application/json" -d "{ \"id\": 1509, \"like\": 1}"

Als laatst doet de API een oproep gebruik makend van het bezoekersnummer vragend naar de gebruikersstatistieken:

● Om de tekstuele informatie te krijgen: curl -X GET "https://motfp.crunchanalytics.cloud/api/statistics_view/902" -H "accept: application/json" -H "authorization: Basic ***************"

Het antwoord:

● Om de afbeelding te verkrijgen: curl -X GET "https://motfp.crunchanalytics.cloud/api/heatmap_view/902" -H "accept: application/json" -H "authorization: Basic ***************"

Het antwoord:

De resultaten worden in het volgende scherm getoond:

7. PowerBI Dashboard

Naast de bezoekers interface, is er ook een dashboard ontwikkelt dat bestemd is voor intern gebruik, om onder meer inzichten te verwerven rond piek- en dalmomenten, interactie met objecten en routes.

Een eerste tabblad focust vooral op de bezoek-drukte op een tijdsas. Daarnaast kunnen de filters gebruikt worden die gebaseerd zijn op wat bezoekers aangeven in de interface (reden bezoek, gezelschap, leeftijd) en wat wij meten (gelopen route, datum).

Een tweede tabblad toont visueel de aantallen tags per route, type gezelschap, reden bezoek en leeftijdsgroepen. Daarnaast is er ook een overzicht van de meest voorkomende bezoekersprofielen en de aanbevelingen, alsook of een aanbeveling positief of negatief bevonden wordt.

Een derde tabblad geeft de plattegrond weer van het verdiep Object Stories en toont de populariteit per object.

Het vierde en laatste tabblad toont de bezoekersstromen en afgelegde paden.

8. Belangrijke Lessen

Het Design museum was geen evidente keuze om dit onderzoeksproject bij uit te voeren. Aangezien vele, diverse objecten dicht bij elkaar kunnen staan wat het moeilijk maakt om 1 positie uniek te karakteriseren.
Daarbij limiteert het gebruik van de POZYX techniek op maar 1 verdieping het opstellen van het gebruikersprofiel. Deze laatste was vooral belangrijk voor het maken van de aanbevelingen naar de bezoekers.
In de toekomst kan het maken van aanbevelingen naar bezoekers verbeterd worden door enerzijds meer informatie van de bezoeker te capteren (door ze bijvoorbeeld te volgen op meerdere verdiepingen) en door datasets te creëren omtrent interessante plaatsen in de stad die gelinkt kunnen worden met het gebruikersprofiel.