This is (more or less) the code that got me my best answer. After reading through a couple of other peoples code, I should have looked more carefully at the time variables, and figured out times etc. Given I got 0.92341 compared to the winners 0.94254, it’s not super important, but it is the small differences that matter.
It’s in R, written up in knitr -> HTML.
Let’s read in some libraries for analysis:
And now let’s read in the data. Im using fread from the data.table package, as it is a large file.
First, how many total bids did each user make? We can assume bots are making a ton.
We group_by bidder_id and then use n() to take the length. n() is a dplyr specific function implemented in rcpp, so is much faster than length or nrow.
Next, we can take the number of bids per auction, on average. Again, I would guess bots are very high.
First, group the data by bidder_id and auction, take the number of bids each user had on each auction.
Then we group it again by user, and find the average for each. mean() is again very fast in dplyr.
Next, number of distinct auctions bid on - This will depend on bot coding - if a bot is used to push up prices on specific auctions, maybe it will have a low number, otherwsie it might be high.
First, let’s group the data into users and auctions, then regroup into users and use n().
Now maybe bots use a user agent switcher so they appear to use different devices? All user agents in this are classed as unique phone models, so if a user uses 8000 phones, they are probably a bot.
again, using pylr we group and and use n().
A bot might only be going after one specific type of merchandise - let’s check
After running this predictor, we get no users with more than 1 type of merchandise! Weird.
So, bots most common (or only!) merchandise might be of a particular type - ie home goods might not be worth coding a bot for. Let’s check - it’s easy as we know there is no replication
Now let’s try country number - someone bidding from multiple countries is up to something.
Now find the most common country - some countries might be more susceptible to bots than others.
I’m going to turn on multiple cores here - dplyr is a little parallelised, so it might help. It definitely will help when it comes to training.
Now let’s do some time series stuff. If the bots are poorly coded, they will always bid exactly, say, 10 seconds after the last bid. So, if we can calculate the diffs for each, we will get a picture of anyone doing something weird.
This is a little trickier, and very slow as it is harder to vectorise. I’ll use diff and add a 0 at the start. We will only run this once, and then use the data frame for multiple analyses.
Now let’s use that data to get mean time since last bid, and the percentage of bids in which the user was the first, and the percentage of bids in which the user was the first. I’m getting mutliple predictors here as they are quicker when gathered at once. call on timediffbids.
Now depending on how the site works, a bid against yourself might be smart (if there is a reserve), or a way of bidding up the price (bot). This one again is slow. Either way, lets make it a feature. Call this on timediffbids.
Now let’s add in the number of final bids. We can assume bots either are trying to jack up prices but lose, or win lots of auctions. Either way there should be a signal here. Let’s get proportion final bids, and total number. Again, run this on the timediffbids.
Now we have a percentage of mismatched bids - It is possible users are more likely to find something in a category noone else used to find it, whereas bots know exactly what they want. We know from above that noone switches type midstream, which simplifies analysis.
Let’s check now for using multiple ipaddresses. This is probably highly correlated with number of countries:
As the phones are based on models, it is possible the bot software is only using a small subset - lets get the most common phone type used for each user.
Shared use of the same ip could be an indication of cheating - let’s find a value for number of shared addresses.
Now let’ do some network analysis. I’m going to connect every user by auctions bid on together (each auction = 2 connections) and get page rank etc from the resulting network. This stuff is memory intensive, I did them both in a seperate session, then added them onto my features csv.
And the same, but for ip addresses. If two users share an ip address, they get a connectedness of two. Again, memory intensive, so not eval here.
share ip with a bot?
How many devices per auction? mean and sd
Now run everthing
Let’s read in the file, and make a couple of composite ones.
Add in the network analysis:
First, let’s set our fitting parameters. I’m using 10 fold crossvalidation
Now we need to merge and partition our data.
First we merge to make sure everything is in a sensible order. We then split out predictors and outcomes.
Random Forest (not run)
Now we can predict!
First read in the test data, and then merge it.
We have 70 bidders in the test data, but not in the bids sheet. Let’s give them 0 as a prediction.