Efficient retrieval of broker estimates

I'm trying to retrieve historical EPS broker estimates for a number of US equities for the last several years. Conceptually, I am trying to do something like:
ek.get_data(rics, ['TR.EPSEstValue.value', 'TR.EPSEstValue.origdate', 'TR.EPSEstValue.broker_id'], parameters={'SDate':'2014-01-01', 'EDate':'2019-06-30', 'Period':'FY-6';FY2'})
Now the above query appears to be prohibitively expensive to run in one shot, and times out. But conversely, if I requested each ric/date/fiscal period individually it would be a prohibitively high number of requests. What is the best way to batch this request? For example, should I request this as a time series (perhaps one per ric), or should I request all the RICs and periods for a particular date and iterate over dates? And would it be more efficient to request multiple fiscal periods or to request those one at a time?
Best Answer
-
For future users, having now done the benchmarking I was hoping to avoid:
1) Requesting additional fiscal periods inside an IBES request does not take appreciably more time (requesting 1 fiscal year and 12 fiscal years is the same amount of time when benchmarked).
2) Adding additional dates to your request increases time by what appears to be a sub-linear factor. However, too many dates at once can cause a request to time out.
3) Adding more securities to a request appears to be roughly linear time increase.
So ultimately I settled on each request requesting 3 months of forecasts for 1 RIC for all available fiscal periods.
0
Answers
-
Hi @davidk
Please refer to this document for API limitation when retrieving a large volume of data.
The effective way is to break down the period you request for to be a smaller period.
For example rather than retrieving data for 5.5 year, you can break it down to 2 years for 3 request on a sample set of RIC codes.
Or reduce the number of RIC codes per request but keep the same period.
Or reduce both number of RIC codes and period.
There is no definitive way to tell you which one is the most effective one.
You have to trial and error on these request and make sure that it is not exceed the API limitation.
0 -
@davidk, thank you for sharing
0
Categories
- All Categories
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 33 Data Model Discovery
- 682 Datastream
- 1.4K DSS
- 613 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 248 ETA
- 552 WebSocket API
- 37 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.8K Refinitiv Data Platform
- 625 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 191 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 83 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛