A key data source for Unsub is the perpetual access date range of each journal--the range of content you'll still have access to, even after a cancellation. If you cancel a Big Deal, perpetual access to back content will become an important source of fulfillment, especially over the first few years.

Of course, this will vary, depending on the journal. In some fields (like math or philosophy), back content stays relevant for a long time, and so perpetual access is quite significant. In other (like biomed), readers are disproportionately reading brand-new articles, and so perpetual access backfile doesn't impact post-cancellation fulfillment that much. The Unsub model accounts for all this, using a training set composed of millions of data points from thousands of libraries, and customized it to your institution using your COUNTER file.

By default, the model assumes that you have full perpetual access rights to all of the journals in your COUNTER file. However, this may not be the case. So, you can upload a list of your actual perpetual access date ranges by journal, and Unsub will recalculate your forecasts using that data. Here's how.

First, navigate to the publisher you're interested, click the Setup tab, and scroll to the Perpetual Access section:

Let's take a closer look at that section:

There are 1,966 journals that are using the default of "Full perpetual access." You'll notice that this in Unsub, this actually just means full perpetual access since 2010. Dates before 2010 are ignored by the forecasting model, because usage of of these older papers is very low,--just a rounding error on overall fulfillment numbers, even in slow-moving fields like philosophy. Ignoring dates before 2010 simplifies the forecasting, without meaningfully affecting accuracy.

You can click on the blue "1,966" number in order to see a list of journals, but it's not very interesting since at this point, it's exactly the same as the list of COUNTER journals the model is using.

So, let's fix that by uploading a custom file and overriding some of those defaults. The file is pretty simple, just a spreadsheet with three columns: ISSN, Start Data, and End Date. A few other tips:

  • For the dates, we prefer an ISO 8601 format like this: YYYY-MM-DD. However, we make our best guess at dates in other formats as well, and they generally work.

  • If a journal's perpetual access is ongoing, leave the End Date blank.

Here's an example:

To upload your file, click the Upload button, then click "Select your file," find your file and select it, then click Upload. You'll wait a minute or two while Unsub uploads and processes the file. Then when it's done, you'll see something like this:

Looking at the "Custom perpetual access dates" section, we can see there are now 1,852 journals where the model will using our custom date ranges. Again, you can click on this number to view the journals and the ranges being used.

You can also see that there were some rows ignored because of errors. If you click on the small blue "9" you can examine each error. In many cases there's a typo or something like that. Sometimes you might get "this looks like an ISSN, but not one we recognize." In that case, your best bet is to check the ISSN and make sure it's legit; if it is, then the bug is our our end. Click the feedback button on the bottom right of the screen or shoot us an email, and we'll get it fixed.

This particular file also contained 686 journals that are not in your COUNTER report (or they are in your COUNTER report, but are being ignored...see the article on uploading your COUNTER for more details on why that might happen). That's fine, we're just letting you know; you don't need to do anything about those.

The last thing to notice is that you've still got 114 journals using the default, because they weren't in your custom file. And that default has now changed: once you upload a custom file, we assume that any journals not in your file have NO perpetual access. If you want to change that, just add those journals to your perpetual access file, and set some dates for them, then re-upload the new file.

Did this answer your question?