Dit is een gastpost van Oliver Frost, datawetenschapper bij ImmoScout24, in samenwerking met Lukas Müller, AWS Solutions Architect.
In 2010, ImmoScout24 heeft een prijsindex voor residentieel vastgoed in Duitsland vrijgegeven: de IMX. Het was gebaseerd op ImmoScout24-lijsten. Naast de prijs bevatten advertenties doorgaans veel specifieke informatie, zoals het bouwjaar, de kavelgrootte of het aantal kamers. Deze informatie stelde ons in staat om een zogenaamde hedonistische prijsindex op te bouwen, die rekening houdt met de specifieke kenmerken van een onroerend goed.
Toen we de IMX uitbrachten, was ons doel om het vast te stellen als de standaardindex voor onroerendgoedprijzen in Duitsland. Het had echter moeite om de prijsstijging op de Duitse vastgoedmarkt sinds de financiële crisis van 2008 te vangen. Bovendien was het, net als een beursindex, een abstract cijfer dat niet direct kan worden geïnterpreteerd. De IMX was daarom moeilijk te vatten voor niet-experts.
Bij ImmoScout24 is het onze missie om complexe beslissingen gemakkelijk te maken, en we realiseerden ons dat we een nieuw concept nodig hadden om dit te vervullen. In plaats van een andere index hebben we besloten een marktrapport op te stellen dat iedereen gemakkelijk kan begrijpen: de WohnBarometer. Het is gebaseerd op onze listinggegevens en houdt rekening met objecteigenschappen. Het belangrijkste verschil met de IMX is dat de WohnBarometer de huur- en verkoopprijzen in euro per vierkante meter weergeeft voor specifieke typen residentieel vastgoed in de loop van de tijd. De cijfers zijn daardoor direct te interpreteren en stellen onze klanten in staat om vragen te beantwoorden als “Betaal ik te veel huur?” of "Is het appartement dat ik ga kopen redelijk geprijsd?" of "Welke stad in mijn regio is het meest veelbelovend om te investeren?" Momenteel wordt de WohnBarometer gerapporteerd voor Duitsland als geheel, de zeven grootste steden en afwisselende lokale markten.
Onderstaande grafiek toont een voorbeeld van de WohnBarometer, met verkoopprijzen voor Berlijn en de ontwikkeling per kwartaal.
Dit bericht bespreekt hoe ImmoScout24 gebruikte Amazon Sage Maker om het model voor de WohnBarometer te maken om het relevant te maken voor onze klanten. Het bespreekt het onderliggende datamodel, de afstemming van de hyperparameter en de technische opzet. Dit bericht laat ook zien hoe SageMaker één datawetenschapper heeft ondersteund om de WohnBarometer binnen 2 maanden te voltooien. Het kostte een heel team 2 jaar om de eerste versie van de IMX te ontwikkelen. Een dergelijke investering was voor de WohnBarometer geen optie.
Over ImmoScout24
ImmoScout24 is het toonaangevende online platform voor residentieel en commercieel vastgoed in Duitsland. Al meer dan 20 jaar heeft ImmoScout24 een revolutie teweeggebracht in de vastgoedmarkt en ondersteunt elke maand meer dan 20 miljoen gebruikers op zijn online marktplaats of in zijn app om nieuwe huizen of commerciële ruimtes te vinden. Daarom kent 99% van onze doelgroep klanten ImmoScout24. Met zijn digitale oplossingen coördineert en brengt de online marktplaats eigenaren, makelaars, huurders en kopers succesvol bij elkaar. ImmoScout24 werkt aan het doel om het proces van vastgoedtransacties te digitaliseren en daarmee complexe beslissingen gemakkelijk te maken. Sinds 2012 is ImmoScout24 ook actief op de Oostenrijkse vastgoedmarkt en bereikt maandelijks ongeveer 3 miljoen gebruikers.
Van on-premises tot AWS Data Pipeline tot SageMaker
In deze sectie bespreken we de vorige opstelling en de uitdagingen, en waarom we besloten om SageMaker te gebruiken voor ons nieuwe model.
De vorige setup
Toen de eerste versie van de IMX in 2010 werd gepubliceerd, was de cloud nog steeds een mysterie voor de meeste bedrijven, ook voor ImmoScout24. Het gebied van machine learning (ML) stond nog in de kinderschoenen en slechts een handvol experts wisten hoe ze een model moesten coderen (ter illustratie: de eerste openbare release van Scikit-Learn was in februari 2010). Het is geen verrassing dat de ontwikkeling van de IMX meer dan 2 jaar duurde en een bedrag van zeven cijfers kostte.
In 2015 begon ImmoScout24 met de AWS-migratie en herbouwde IMX op de AWS-infrastructuur. Met de gegevens in onze Amazon eenvoudige opslagservice (Amazon S3) data lake, zowel de voorverwerking van de gegevens als de modeltraining waren nu gedaan op Amazon EMR clusters georkestreerd door AWS-gegevenspijplijn. Terwijl de eerste een PySpark ETL-toepassing was, waren de laatste verschillende Python-scripts die klassieke ML-pakketten gebruikten (zoals Scikit-Learn).
Problemen met deze opstelling
Hoewel deze setup vrij stabiel bleek te zijn, was het oplossen van problemen met de infrastructuur of het verbeteren van het model niet eenvoudig. Een belangrijk probleem met het model was de complexiteit ervan, omdat sommige componenten een eigen leven waren begonnen: uiteindelijk was de code van de uitbijterdetectie bijna twee keer zo lang als de code van het IMX-kernmodel zelf.
Het kernmodel was eigenlijk niet één model, maar honderden: één model per woningtype en regio, waarbij de definitie varieerde van een enkele wijk in een grote stad tot meerdere dorpen op het platteland. We hadden bijvoorbeeld een model voor appartementen te koop in het midden van Berlijn en een model voor huizen te koop in een buitenwijk van München. Omdat het opzetten van de training van al deze modellen veel tijd kostte, hebben we de hyperparameter-tuning achterwege gelaten, waardoor de modellen waarschijnlijk ondermaats presteerden.
Waarom we voor SageMaker hebben gekozen
Gezien deze problemen en onze ambitie om een marktrapport met praktische voordelen te hebben, moesten we kiezen tussen grote delen van de bestaande code herschrijven of helemaal opnieuw beginnen. Zoals je uit dit bericht kunt afleiden, hebben we voor het laatste gekozen. Maar waarom SageMaker?
De meeste tijd die we aan de IMX besteedden, ging naar het oplossen van problemen met de infrastructuur, niet met het verbeteren van het model. Voor het nieuwe marktrapport wilden we dit omdraaien, met de focus op de statistische prestaties van het model. We wilden ook de flexibiliteit hebben om snel individuele componenten van het model te vervangen, zoals de optimalisatie van de hyperparameters. Wat als er een nieuw superieur boost-algoritme komt (denk aan hoe XGBoost in 2014 op het podium verscheen)? We willen hem natuurlijk als een van de eersten adopteren!
In SageMaker zijn de belangrijkste componenten van de klassieke ML-workflow - preprocessing, training, hyperparameterafstemming en inferentie - netjes gescheiden op het API-niveau en ook op het AWS-beheerconsole. Ze individueel aanpassen is niet moeilijk.
Het nieuwe model
In deze sectie bespreken we de componenten van het nieuwe model, inclusief de invoergegevens, het algoritme, de afstemming van hyperparameters en de technische instellingen.
Invoergegevens
De WohnBarometer is gebaseerd op een schuifraam van 5 jaar ImmoScout24-lijsten van residentieel onroerend goed in Duitsland. Nadat we uitbijters en frauduleuze vermeldingen hebben verwijderd, blijven er ongeveer 4 miljoen vermeldingen over die zijn opgesplitst in treingegevens (60 %), validatie (20 %), en testgegevens (20 %). De relatie tussen listings en objecten is niet noodzakelijk 1:1; in de loop van 5 jaar is het waarschijnlijk dat hetzelfde object meerdere keren (door meerdere mensen) wordt ingevoegd.
We gebruiken 13 advertentiekenmerken, zoals de locatie van het onroerend goed (WGS84-coördinaten), het type onroerend goed (huis of appartement, koop of huur), de leeftijd (jaren), de grootte (vierkante meter) of de staat (bijvoorbeeld , nieuw of gerenoveerd). Aangezien elke vermelding doorgaans met tientallen attributen wordt geleverd, rijst de vraag: welke moet in het model worden opgenomen? Enerzijds maakten we gebruik van domeinkennis; het is bijvoorbeeld algemeen bekend dat locatie een sleutelfactor is, en in bijna alle markten is nieuw vastgoed duurder dan bestaand vastgoed. Aan de andere kant vertrouwden we op onze ervaringen met de IMX en vergelijkbare modellen. Daar leerden we dat het opnemen van tientallen attributen het model niet significant verbetert.
Afhankelijk van het type onroerend goed van de aanbieding, is de doelvariabele van ons model ofwel de huur per vierkante meter of de verkoopprijs per vierkante meter (we leggen later uit waarom deze keuze niet ideaal was). In tegenstelling tot de IMX is de WohnBarometer daarom een getal dat direct door onze klanten kan worden geïnterpreteerd en opgevolgd.
Model Omschrijving
Wanneer u SageMaker gebruikt, kunt u kiezen tussen verschillende strategieën om uw algoritme te implementeren:
- Gebruik een van de ingebouwde algoritmen van SageMaker. Er zijn er bijna 20 en ze dekken alle belangrijke typen ML-problemen.
- Pas een vooraf gemaakte Docker-afbeelding aan op basis van een standaard ML-framework (zoals Scikit-Learn of PyTorch).
- Bouw uw eigen algoritme en implementeer het als een Docker-image.
Voor de WohnBarometer wilden we een oplossing die gemakkelijk te onderhouden is en ons in staat stelt ons te concentreren op het verbeteren van het model zelf, niet de onderliggende infrastructuur. Daarom hebben we gekozen voor de eerste optie: gebruik een volledig beheerd algoritme met de juiste documentatie en snelle ondersteuning indien nodig. Vervolgens moesten we het algoritme zelf kiezen. Nogmaals, de beslissing was niet moeilijk: we gingen voor het XGBoost-algoritme omdat het een van de meest bekende ML-algoritmen is voor problemen met het regressietype, en we hebben het al met succes in verschillende projecten gebruikt.
Hyperparameterafstemming
De meeste ML-algoritmen worden geleverd met een groot aantal parameters om aan te passen. Boosting-algoritmen hebben bijvoorbeeld veel parameters die aangeven hoe de bomen precies worden gebouwd: hebben de bomen maximaal 20 of 30 bladeren? Is elke boom gebaseerd op alle rijen en kolommen of alleen op steekproeven? Hoe zwaar de bomen snoeien? Het vinden van de optimale waarden van die parameters (zoals gemeten door een evaluatiemetriek van uw keuze), de zogenaamde hyperparameterafstemming, is van cruciaal belang voor het bouwen van een krachtig ML-model.
Een belangrijke vraag bij het afstemmen van hyperparameters is welke parameters moeten worden afgestemd en hoe de zoekbereiken moeten worden ingesteld. U vraagt zich misschien af, waarom niet alle mogelijke combinaties aanvinken? Hoewel dit in theorie een goed idee klinkt, zou het resulteren in een enorme hyperparameterruimte met veel te veel punten om ze allemaal tegen een redelijke prijs te evalueren. Dat is de reden waarom ML-beoefenaars doorgaans een klein aantal hyperparameters selecteren waarvan bekend is dat ze een sterke invloed hebben op de prestaties van het gekozen algoritme.
Nadat de hyperparameterruimte is gedefinieerd, is de volgende taak om de beste combinatie van waarden erin te vinden. De volgende technieken worden vaak gebruikt:
- Raster zoeken – Verdeel de ruimte in een discreet raster en evalueer vervolgens alle punten in het raster met kruisvalidatie.
- Willekeurig zoeken - Trek willekeurig combinaties uit de ruimte. Met deze aanpak mis je waarschijnlijk de beste combinatie, maar het dient als een goede maatstaf.
- Bayesiaanse optimalisatie – Bouw een probabilistisch model van de doelfunctie en gebruik dit model om nieuwe combinaties te genereren. Na elke combinatie wordt het model geüpdatet, wat snel tot goede resultaten leidt.
Dankzij goedkope rekenkracht is Bayesiaanse optimalisatie de afgelopen jaren de gouden standaard geworden in het afstemmen van hyperparameters en is het de standaardinstelling in SageMaker.
Technische opzet
Net als bij veel andere AWS-services, kunt u SageMaker-taken op de console maken met de AWS-opdrachtregelinterface (AWS CLI), of via code. We kozen voor de derde optie, de SageMaker Python SDK om precies te zijn, omdat het een sterk geautomatiseerde setup mogelijk maakt: de WohnBarometer leeft in een Python-softwareproject dat via de opdrachtregel kan worden uitgevoerd. Alle stappen van de ML-pijplijn, zoals de preprocessing of de modeltraining, kunnen bijvoorbeeld worden geactiveerd via Bash-commando's. Die Bash-commando's worden op hun beurt georkestreerd met een Jenkins-pijplijn, mogelijk gemaakt door AWS Fargate.
Laten we eens kijken naar de stappen en de onderliggende infrastructuur:
- Voorverwerking – De voorbewerking gebeurt met de ingebouwde Scikit-Learn-bibliotheek in SageMaker. Omdat het gaat om het samenvoegen van dataframes met miljoenen rijen, hebben we hier een ml.m5.24xlarge machine nodig, de grootste die je kunt krijgen in de ml.m-familie. Als alternatief hadden we meerdere kleinere machines kunnen gebruiken met een gedistribueerd framework zoals Dask, maar we wilden het zo eenvoudig mogelijk houden.
- Trainingen – We gebruiken het standaard SageMaker XGBoost-algoritme. De training wordt gedaan met twee ml.m5.12xlarge machines. Het is vermeldenswaard dat onze train.py met de code van de modeltraining en de hyperparameter-afstemming minder dan 100 rijen heeft.
- Hyperparameterafstemming - Volgens het principe van minder is meer, stemmen we slechts 11 hyperparameters af (bijvoorbeeld het aantal boost-rondes en de leersnelheid), wat ons de tijd geeft om hun bereiken zorgvuldig te kiezen en te inspecteren hoe ze met elkaar omgaan. Met slechts een paar hyperparameters verloopt elke trainingstaak relatief snel; in ons geval duren de klussen tussen de 10-20 minuten. Met een maximaal aantal van 30 opleidingsopdrachten en 2 gelijktijdige opdrachten bedraagt de totale opleidingstijd ongeveer 3 uur.
- Gevolgtrekking – SageMaker biedt meerdere opties om uw model te bedienen. We gebruiken batchtransformatietaken omdat we de WohnBarometer-nummers maar één keer per kwartaal nodig hebben. We hebben geen eindpunt gebruikt omdat het het grootste deel van de tijd inactief zou zijn. Elke batchtaak (ongeveer 6.8 miljoen rijen) wordt in minder dan 5.4 minuten door een enkele ml.m10xgrote machine bediend.
We kunnen deze stappen eenvoudig debuggen op de SageMaker-console. Als een opleidingsopdracht bijvoorbeeld langer duurt dan verwacht, navigeren we naar de Trainingen pagina, zoek de betreffende trainingstaak en bekijk Amazon Cloud Watch metrieken van de onderliggende machines.
Het volgende architectuurdiagram toont de infrastructuur van de WohnBarometer:
Uitdagingen en lessen
In het begin verliep alles soepel: binnen een paar dagen hebben we het softwareproject opgezet en een miniatuurversie van ons model in SageMaker getraind. We hadden hoge verwachtingen van de eerste run op de volledige dataset en de hyperparameter-afstemming op zijn plaats. Helaas waren de resultaten niet bevredigend. We hadden de volgende belangrijke problemen:
- De voorspellingen van het model waren te laag, zowel voor huur- als verkoopobjecten. Voor Berlijn bijvoorbeeld lagen de voorspelde verkoopprijzen voor onze referentieobjecten ongeveer 50% onder de marktprijzen.
- Volgens het model was er geen significant prijsverschil tussen nieuwbouw en bestaande bouw. De waarheid is dat nieuwe gebouwen bijna altijd aanzienlijk duurder zijn dan bestaande gebouwen.
- Het effect van de locatie op de prijs is niet correct weergegeven. We weten bijvoorbeeld dat appartementen die te koop staan in Frankfurt am Main, gemiddeld duurder zijn dan in Berlijn (hoewel Berlijn een inhaalslag maakt); ons model voorspelde het echter andersom.
Wat was het probleem en hoe hebben we het opgelost?
Bemonstering van de functies
Op het eerste gezicht lijken de problemen niets met elkaar te maken te hebben, maar dat zijn ze inderdaad. Standaard bouwt XGBoost elke boom met een willekeurig voorbeeld van de functies. Laten we zeggen dat een model 10 functies heeft F1, F2, … F10, dan kan het algoritme F . gebruiken1, F4, en F7 voor één boom, en F3, F4, en F8 voor een ander. Hoewel dit gedrag over het algemeen overfitting effectief voorkomt, kan het problematisch zijn als het aantal kenmerken klein is en sommige een groot effect hebben op de doelvariabele. In dit geval zullen veel bomen de cruciale kenmerken missen.
XGBoost's steekproef van onze 13 kenmerken leidde tot veel bomen, waaronder geen van de cruciale kenmerken - type onroerend goed, locatie en nieuwe of bestaande gebouwen - en veroorzaakten als gevolg daarvan deze problemen. Gelukkig is er een parameter om de bemonstering te regelen: colsample_bytree
(in feite zijn er nog twee parameters om de bemonstering te regelen, maar die hebben we niet aangeraakt). Toen we onze code controleerden, zagen we dat colsample_bytree
werd ingesteld op 0.5, een waarde die we uit eerdere projecten hebben overgenomen. Zodra we het op de standaardwaarde van 1 hadden ingesteld, waren de voorgaande problemen verdwenen.
Eén model versus meerdere modellen
In tegenstelling tot de IMX is het WohnBarometer-model eigenlijk maar één model. Hoewel dit de onderhoudsinspanning minimaliseert, is het vanuit statistisch oogpunt niet ideaal. Omdat onze trainingsgegevens zowel verkoop- als huurobjecten bevatten, is de spreiding in de doelvariabele enorm: deze varieert van minder dan 5 euro voor sommige huurappartementen tot ruim boven de 10,000 euro voor huizen te koop op eersteklas locaties. De grote uitdaging voor het model is om te begrijpen dat een fout van 5 euro fantastisch is voor verkoopobjecten, maar rampzalig voor huurobjecten.
Achteraf gezien, als we wisten hoe gemakkelijk het is om meerdere modellen in SageMaker te onderhouden, zouden we minstens twee modellen hebben gebouwd: een te huur en een te koop. Dit zou het gemakkelijker maken om de eigenaardigheden van beide markten te vangen. Zo is de prijs van niet-verhuurde appartementen die te koop staan doorgaans 20-30% hoger dan die van huurappartementen die te koop staan. Daarom is het heel logisch om deze informatie als een dummyvariabele in het verkoopmodel te coderen; voor het huurmodel daarentegen zou je het weg kunnen laten.
Conclusie
Heeft de WohnBarometer het doel bereikt om relevant te zijn voor onze klanten? Met media-aandacht als indicatie, is het antwoord een duidelijk ja: vanaf november 2021 zijn er meer dan 700 krantenartikelen en tv- of radioreportages over de WohnBarometer gepubliceerd. Op de lijst staan landelijke dagbladen zoals Frankfurter Allgemeine Zeitung, Tagesspiegel en Handelsblatt, en lokale kranten die vaak vragen naar WohnBarometer-cijfers voor hun regio. Omdat we de cijfers toch voor alle regio's van Duitsland berekenen, nemen we dergelijke verzoeken graag aan. Met de oude IMX was dit niveau van granulariteit niet mogelijk.
De WohnBarometer presteert beter dan de IMX wat betreft statische prestaties, vooral als het gaat om de kosten: de IMX werd gegenereerd door een EMR-cluster met 10 taakknooppunten die bijna een halve dag draaien. Daarentegen nemen alle WohnBarometer-stappen minder dan 5 uur in beslag met middelgrote machines. Dit resulteert in een kostenbesparing van bijna 75%.
Dankzij SageMaker konden we in minder dan 2 maanden met één datawetenschapper een complex ML-model in productie brengen. Dit is opmerkelijk. 10 jaar eerder, toen ImmoScout24 de IMX bouwde, duurde het bereiken van dezelfde mijlpaal meer dan 2 jaar en was er een heel team bij betrokken.
Hoe kunnen we zo efficiënt zijn? Met SageMaker konden we ons concentreren op het model in plaats van op de infrastructuur, en SageMaker promoot een microservice-architectuur die gemakkelijk te onderhouden is. Als we ergens mee vast kwamen te zitten, konden we een beroep doen op AWS-ondersteuning. In het verleden, wanneer een van onze IMX-gegevenspijplijnen faalde, waren we soms dagen bezig om deze te debuggen. Sinds we in april 2021 zijn begonnen met het publiceren van WohnBarometer-cijfers, heeft de SageMaker-infrastructuur nog geen enkele keer gefaald.
Ga voor meer informatie over de WohnBarometer naar WohnBarometer en WohnBarometer: Angebotsmieten stiegen 2021 bundesweit wieder starker an. Voor meer informatie over het gebruik van de SageMaker Scikit-Learn-bibliotheek voor voorbewerking, zie: Invoergegevens voorverwerken voordat u voorspellingen doet met behulp van Amazon SageMaker-inferentiepijplijnen en Scikit-learn. Stuur ons alstublieft feedback, hetzij op de AWS-forum voor Amazon SageMaker, of via uw AWS-ondersteuningscontacten.
De inhoud en meningen in dit bericht zijn die van de externe auteur en AWS is niet verantwoordelijk voor de inhoud of nauwkeurigheid van dit bericht.
Over de auteurs
Oliver Vorst kwam in 24 bij ImmoScout2017 als bedrijfsanalist. Twee jaar later werd hij een datawetenschapper in een team wiens taak het is om ImmoScout24-gegevens om te zetten in echte dataproducten. Voordat hij het WohnBarometer-model bouwde, leidde hij kleinere SageMaker-projecten. Oliver is in het bezit van verschillende AWS-certificaten, waaronder de Machine Learning Specialty.
Lukas Muller is Solutions Architect bij AWS. Hij werkt met klanten in de sport-, media- en entertainmentindustrie. Hij is altijd op zoek naar manieren om technische ondersteuning te combineren met culturele en organisatorische ondersteuning om klanten te helpen zakelijke waarde te realiseren met cloudtechnologieën.
- Coinsmart. Europa's beste Bitcoin- en crypto-uitwisseling.
- Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. GRATIS TOEGANG.
- CryptoHawk. Altcoin-radar. Gratis proefversie.
- Bron: https://aws.amazon.com/blogs/machine-learning/predict-residential-real-estate-prices-at-immoscout24-with-amazon-sagemaker/
- "
- 000
- 100
- 11
- 20 jaar
- 2021
- Over
- Account
- actieve
- algoritme
- algoritmen
- Alles
- al
- Hoewel
- Amazone
- analist
- Nog een
- api
- gebruiken
- Aanvraag
- nadering
- April
- architectuur
- rond
- artikelen
- geautomatiseerde
- gemiddelde
- AWS
- worden
- Begin
- wezen
- criterium
- betekent
- BEST
- Grootste
- het stimuleren
- bouw
- Gebouw
- bouwt
- ingebouwd
- bedrijfsdeskundigen
- ondernemingen
- kopen
- Bellen
- Kan krijgen
- veroorzaakt
- certificaten
- uitdagen
- uitdagingen
- Steden
- Plaats
- Cloud
- code
- combinatie van
- combinaties
- commercieel
- complex
- Berekenen
- concept
- voorwaarde
- beschouwt
- troosten
- bouw
- bevat
- content
- onder controle te houden
- Kern
- Kosten
- kon
- crisis
- cruciaal
- Klanten
- gegevens
- data scientist
- dag
- implementeren
- Opsporing
- ontwikkelen
- Ontwikkeling
- DEED
- anders
- digitaal
- bespreken
- verdeeld
- havenarbeider
- Nee
- domein
- gemakkelijk
- effect
- doeltreffend
- Endpoint
- enorm
- Onstpanning
- oprichten
- vastgoed
- Euro
- iedereen
- alles
- voorbeeld
- verwacht
- Ervaringen
- deskundigen
- familie
- SNELLE
- Voordelen
- feedback
- Figuur
- financieel
- financiële crisis
- Voornaam*
- Flexibiliteit
- Focus
- volgend
- Achtergrond
- vervullen
- vol
- functie
- Algemeen
- voortbrengen
- Duitsland
- oogopslag
- doel
- Tijdloos goud
- goed
- Raster
- Groep
- Gast
- Gast Bericht
- gelukkig
- met
- hulp
- hier
- Hoge
- zeer
- houdt
- Huis
- huizen
- Hoe
- How To
- HTTPS
- reusachtig
- Honderden
- idee
- beeld
- Impact
- verbeteren
- omvatten
- Inclusief
- Laat uw omzet
- index
- individueel
- industrieën
- informatie
- Infrastructuur
- investeren
- investering
- betrokken zijn
- problemen
- IT
- Jobomschrijving:
- Vacatures
- toegetreden
- sleutel
- kennis
- bekend
- Groot
- leidend
- LEARN
- geleerd
- leren
- LED
- Niveau
- Bibliotheek
- Lijn
- Lijst
- vermelding
- Meldingen
- lokaal
- plaats
- locaties
- lang
- op zoek
- machine
- machine learning
- Machines
- groot
- maken
- management
- Markt
- Marktverslag
- markt
- Markten
- Media
- Metriek
- miljoen
- miljoenen
- Missie
- ML
- model
- modellen
- maanden
- meest
- nationaal
- Nieuwe markt
- Kranten
- knooppunten
- nummers
- Aanbod
- online.
- online marktplaats
- Meningen
- optimalisatie
- Keuze
- Opties
- bestellen
- Overige
- eigenaren
- Samenwerking
- Betaal
- Mensen
- prestatie
- platform
- Oogpunt
- mogelijk
- energie
- krachtige
- Voorspellingen
- prijs
- probleem
- problemen
- productie
- Producten
- project
- projecten
- veelbelovend
- eigendom
- publiek
- Reclame
- Quarter
- vraag
- snel
- Radio
- vastgoed
- redelijk
- verwantschap
- los
- Vermaard
- Verhuur
- verslag
- Rapporten
- verantwoordelijk
- Resultaten
- beoordelen
- Studio's
- ronde
- rondes
- lopen
- lopend
- landelijk
- Platteland
- sale
- Wetenschapper
- sdk
- Ontdek
- zin
- Diensten
- reeks
- het instellen van
- aanzienlijke
- gelijk
- Eenvoudig
- Maat
- Klein
- So
- Software
- Oplossingen
- OPLOSSEN
- iets
- Tussenruimte
- ruimten
- besteden
- spleet
- Sport
- verspreiden
- vierkant
- Stadium
- gestart
- statistisch
- voorraad
- beurs
- mediaopslag
- strategieën
- sterke
- Met goed gevolg
- superieur
- ondersteuning
- ondersteunde
- steunen
- verrassing
- doelwit
- team
- Technisch
- technieken
- Technologies
- proef
- van derden
- Door
- niet de tijd of
- samen
- Trainingen
- Transacties
- Transformeren
- tv
- begrijpen
- us
- .
- gebruikers
- waarde
- Bekijk
- Wat
- binnen
- werkzaam
- Bedrijven
- waard
- jaar
- jaar