The difference between api value and screen value
-
When I check the two parameters (PA and DA values) actually, these values often differ from those which I receive from your API. Why does it happen?
-
Thanks for the response! And thanks for the advice!
-
Redirects:
yyxysh.com -> DA=8; UPA = 17 in OSE, API {"pda":7.946532082305239,"upa":16.535296818533226}
www.yyxysh.com -> DA=8; UPA=21; {"pda":7.946532082305239,"upa":21.185637908436604}zaegi.com -> 17/27; {"pda":17.31598169835115,"upa":27.430491280580874}
www.zaegi.com -> 17/13; {"pda":17.31598169835115,"upa":13.339025908887258}As you can see API and OSE works. But checking different domain screw test. Please check your software did add "www" in beginning of checks? Because mine tests shows that it ADD it.
If you have Mac then you can use mine SEOAuditor very small app that return few important metrics:
http://www.mobiliodevelopment.com/seoauditor/
Actual API examples are from it. I just enable "debug log" to get raw results. -
I don't think the difference I observed came from rounding because it varied quite more than the difference of rounding range! For instance, in the domain of "yyxysh.com", I observed UPA as 17 directly via OSE. On the other hand, API output UPA as 21.1856379084366. In another case, in the domain of "zaegi.com", I confirmed 27 via OSE in contrast to 13.3390259088872 via API. I assume such a difference doesn't come from a time lag because API refreshes the current values such as UPA within 1 hour before or after OSE refreshes. I found about 50% of samples encountered such a value difference after my investigation for a few days. Therefore, I hope you would give me additional advice or cause about the phenomenon. Thank you very much for your help in advance.
-
Dev that use API here.
Yes - they're different sometimes because rounding. In OSE you get numbers as PDA 25.294393094636707 and UPA 36.15102264746345. And Moz OSE round them to 25 and 36. This is ok. But on mine other site bgdn.net as response get{"pda":22.949587785824708,"upa":27.22655880092715}. OSE shows 23 and 27.
If you post some URL with difference here we can debug and see difference.
Got a burning SEO question?
Subscribe to Moz Pro to gain full access to Q&A, answer questions, and ask your own.
Browse Questions
Explore more categories
-
Moz Tools
Chat with the community about the Moz tools.
-
SEO Tactics
Discuss the SEO process with fellow marketers
-
Community
Discuss industry events, jobs, and news!
-
Digital Marketing
Chat about tactics outside of SEO
-
Research & Trends
Dive into research and trends in the search industry.
-
Support
Connect on product support and feature requests.
Related Questions
-
Unsolved Api limits on free plan
Good afternoon. I tried connecting free access to api https://moz.com/help/links-api/v1-archive/v1-free-api-access to retrieve DA data. After several requests to the api I got a message: "Your monthly row limit reached" Can you tell me what this error is related to? Or Moz doesn't have free api access anymore?
API | | Dima124dsfg1 -
Unsolved Does Anyone use DashThis API with MOZ?
Hi Team
API | | SkyrailCairns
Looking to share MOZ API credentials with DashThis - They provide an all in one reporting solution for all aspects of digital marketing.
Does anyone use DashThis?0 -
API url_metrics Error deserializing POST body
Getting error in https://lsapi.seomoz.com/v2/url_metrics API I'm using Basic Auth for authentication. { "name": "Bad Request", "message": "Error deserializing POST body"} CVW2T4f
API | | verdet32321 -
Unknown data items in Links API response
So I'm on the documentation page at https://moz.com/help/links-api/making-calls/url-metrics . I've copied the bit fields table into a spreadsheet. I've removed all the "deprecated" items and have totalled up the remaining items making a Cols= value of 182537205900657000. For want of better knowledge, I've used that same value for LinkCols=, SourceCols= and TargetCols=. The request url ends up being (anonymized): http://lsapi.seomoz.com/linkscape/links/fordanddoonan.com.au?Cols=182537205900657000&AccessID=xxx&Expires=1557458487346&Signature=xxx&SourceCols=182537205900657000&TargetCols=182537205900657000&LinkCols=182537205900657000&Limit=1000&Scope=page_to_domain&Filter=external My question is, what do I make of all the extra fields that I get in the json packet what should I do to remove them? These extra fields are: lrid, lsrc, ltgt, luufq, luueid, lufeid, luujid, luumrp, luumrr, luflan, lufspf, lufsplc, lufspp, lufsps, lufspsc, luus, lufuid, lupuid, lufipl, luupa, lupda, luued, lufed, luped, lupib, luulc, flan, fspf, fsplc, fspp, fsps Is it simply a case of limiting the values of TargetCols, LinkCols and SourceCols? If so, to what?
API | | StevePoul1 -
Mozscape API Updates (Non-updates!) - becoming a joke!
This is the 3rd month in succession where the Mozscape index has been delayed. Myself and clients are losing patience with this, as I am sure many others must be. Just what do you suppose we tell clients waiting for that data? We have incomplete and sometimes skewed metrics to report on, delays which then get delayed further, with nothing but the usual 'we are working on it' and 'bear with us'. It's becoming obvious you fudged the index update back in January (see discussion here with some kind of explanation finally from Rand: https://moz.com/community/q/is-everybody-seeing-da-pa-drops-after-last-moz-api-update), and seems you have been fumbling around ever since trying to fix it, with data all over the place, shifting DA scores and missing links from campaign data. Your developers should be working around the clock to fix this, because this is a big part of what you're selling in your service, and as SEO's and marketers we are relying on that data for client retention and satisfaction. Will you refund us all if we should lose clients over this?! .. I don't think so! With reports already sent out the beginning of the month with incomplete data, I told clients the index would refresh April 10th as informed from the API updates page, only to see it fudged again on day of release with the index being rolled back to previous. So again, I have to tell clients there will be more delays, ...with the uncertainty of IF it WILL EVEN get refreshed when you say it will. It's becoming a joke.. really!
API | | GregDixson2 -
API: General information URL on path level
Is it possible to get general information (refdomains, mozrank etc.) out of the API on path level? If so, what is the best way to do this? Example www.test.com/folder/ -> Combined data (for example, total refdomains etc) for all URL’s indexed by Moz that include www.test.com/folder/ -> like www.test.com/folder/item/page.html and www.test.com/folder/page2.html
API | | MerkleNederland0 -
Cannot get the API to work when using an EC2 server
Hi I've created a script that I'd like to use to check a list of domains using the Moz API. It works totally fine on my local machine. However, when I run it from my EC2 instance, it fails every time. To be specific, the response is always empty (the response is an empty json array) when the request is sent from EC2. Is, for some reason, EC2 blocked by the Moz API? Many thanks for your help, Andrew
API | | csandrew0 -
Are EC2 servers blocked from using the Moz API?
Hi I've created a script that I'd like to use to check a list of domains using the Moz API. It works totally fine on my local machine. However, when I run it from my EC2 instance, it fails every time. To be specific, the response is always empty (the response is an empty json array) when the request is sent from EC2. Is, for some reason, EC2 blocked by the Moz API? Many thanks for your help, Andrew
API | | csandrew0