mgontav

This was pretty much my experience as well: had to build a small scraper 2 years ago to alert me whenever spots for camping became available in Yosemite. Bear in mind that this was around 3-4 months in advance. Just for the sake of it I let it run after we had the spots, to understand how many people cancelled, and the amount of cancellations are actually insane.

While I don't think my approach was too harsh (I wasn't constantly querying nor booking automatically), it could be solved if they provided their own alert system, or discourage the book-cancel behaviour (higher cancel fees? Might not make much sense since the camping itself is pretty cheap...)

Thanks for reporting it, we believe to have fixed it in the meanwhile, feel free to keep testing.

Sure thing, shoot me an email at [email protected] and we'll see how we can help you out.

Well, if we provide confidence intervals it should provide some kind of "safety"... but even so, with forecasting the only assurance you can get is by testing it against known historical values and checking it's accuracy (and even that way, historical results are no guarantee of future performance).

What kind of details would you say can be inspected to see if the model is reliable? AR or MA orders, inferred seasonalities? They can give me some notion of what kinds of assumptions were created about my data, but do not guarantee that it will perform :/

For instances where that kind of insight is needed, I don't think our way is the way to go, but rather the use of some forecasting package (R's Forecast or FB's Prophet) and a more exploratory work. But we're looking more at instances where what matters are the forecasted values and not so much the information underneath - automated anomaly detection systems, consumer-facing apps, and along those lines.

We've been expecting this question all day long.

As fate has it, we have no connection to FB's Prophet - we at Whitesmith have been working on unplugg for some time now and decided a few weeks ago that this week we'd share it on some communities to have more people testing it and more feedback. It seems that the folks over at Facebook decided something similar. You know what they say, great minds :p

Joking aside, as intimidating as it might have been to see FB releasing a related tool, we feel that we still fill a different segment. From what I've been reading today, Prophet is a tool tailored for timeseries forecasting with human interaction and input in mind - it can work like a black forecasting box but it seems that it is the most useful when paired with an analyst that can keep looking at the output and tweak the model accordingly. It is _really friendly_ as far as forecasting packages go and trust me, we looked at a fair amount of them. That and the use of ProbProgramming to infer their params is just awesome (I'm a fervent Bayesian at heart).

Unplugg on the other hand, fills the need for a "generic" forecasting tool for uses where you don't want/need much specific tailoring and want a really Plug&Play solution - it's an API that you can call from pretty much everywhere, with no dependencies or specific environments needed (so no need to deploy your own R/Python/Matlab - yikes - environment where your models live and run). One possible use case would be an energy monitoring portal that lives completely client-side and requests forecasts to our API on-the-fly directly from the client.

We are still actively developing and testing different forecasting models - the one running is just the one we feel most confident about - and will be looking at Prophet as a possible alternative (although I haven't seen their license carefully, so can't be sure).

Remnants of working with energy consumption and smart meter data - our examples are still a bit focused on that. On the other hand, the current version is able to handle distinct/heterogeneous intervals, although it clearly does not perform as well. We try (maybe too) hard to mangle the incoming data into something as _standard_ as possible for our models, and sometimes those transforms are not kind to sparse data.

Yeah, it's kind of verbose right now :p We'll get around to it when we make sure the forecast is the best it can be.

EDIT: But XML payloads are actually a really useful idea, it's going ASAP to the Trello board. :p

We could return a confidence interval for the forecasted values, you're right, it can help in cases where it would be used for simple anomaly detection (and it would give a greater sense of security/control over using the forecast).

I do believe we have some similar feature in the pipeline for development, I'll make sure to push it forward. Thanks for the feedback.

Not really. We're directing this more towards a completely automated use-case of forecasting with no human interaction, so it's not on our plans to release internal parameterization of the forecast.

Cool! Get back to us with feedback on how it went, we're looking for as much input as possible at this point.

Hey, you can still try it out as is, just request an API key and start using it. Unless you're worried about sending data out into unknown servers... in that case I can assure you we keep absolutely no information on the data we receive to be processed. Our initial use-case of energy consumption forecasting demanded this kind of data policy, and we're sticking to it.

Our goal is to keep it as simple as we can, keeping the worries about model selection and tuning on our side as much as possible, therefore we don't go much into those details.

I can share that our platform is built on top of ARIMA models, but with a lot of pre-processing work done previously to try and figure out automatically the best parameters to use, as well as a lot of previous hand-tweaking done by ourselves in-house using different datasets (we started out tuning it for forecasting energy consumption, but figured that the resulting models were performing well enough to warrant testing in other domains).

Right now we're opening it up for testing to get more feedback on its performance, so feel free to shoot any more questions or feedback.

We allow for you to specify the limit of the forecasting period, so you can experiment with that.

However, due to how we model the forecast, it isn't realistic to expect ultra-long term predictions, as eventually the forecast will revert to the mean of the series.

In a more practical note, we have seen good results with forecast windows in between 1/4 and 1/8 the size of the historic data given. So, in your case you could expect between 1-3 months of forecast.