EODHD-difference-between-EOD-vs-intraday-data

Update:
A courageous Data Manager->Historical Providers->EODHD->right mouse->Delete Local Files
did not change the situation.

Intraday close - the last full lot trade in the regular session.
Daily close - the settlement price, which can occur several minutes after the close.

There's no guarantee that these prices will be the same, and frankly, they're frequently different.

Edit -
I didn't look at your example, which is showing something different - clearly some sort of adjustment.

Using Norgate Data, you can check unadjusted and adjusted prices -

ADP for 2020-01-29

Unadjusted
O = 171.85
C = 171.04

Adjusted for Dividends
O = 157.9760
C = 157.2314

QUOTE:
Using Norgate Data..

Ok, this means the EODHD data extension provides adjusted EOD data that matches the Norgate data.

Intraday data from EODHD is not adjusted creating the aforementioned mismatch.

May I ask for a #FeatureRequest which makes intraday data from EODH adjusted so it matches the EOD data from the same provider?

(Else Granular Processing does not make much sense...)

Isn't it an industry standard to deliver intraday data unadjusted? Not only EODHD does this, and I don't think we should change this.

Would this unadjusted data make a big difference in granular backtesting?

I ask because I just got intra-day data from EODHD and ran a granular backtest on a dip buyer strategy and the results were much worse than the normal backtest and they were even worse than the worst Monte Carlo results using same date scramble.

Would dividends make much of a difference if my hold period is only one day?

QUOTE:
Would this unadjusted data make a big difference in granular backtesting?

Well, if intraday data does not match EOD data then granular processing for this symbol/bar is simply disabled, i.e. the backtest results (for this symbol and data range) are the same as without granular processing.

Usually this will make the backtest results of a limit order system better.

Or - to put it the other way round - unadjusted data will make the results from backtests less realistic.

QUOTE:
intraday data unadjusted ... I don't think we should change this.

Ok, if we accept intraday data being unadjusted, then:

Granular processing should take this mismatch into account and adapt intraday data to EOD data, i.e. multiply the intraday series of the current day by (EOD_OPEN) / (Intraday_Open) before doing its processing (searching the correct entry time).

Let's make this a #FeatureRequest.

QUOTE:
multiply the intraday series of the current day by (EOD_OPEN) / (Intraday_Open) before doing its processing

Good solution!

Although to save cycles I'd change it to, "multiply the intraday price by (EOD_OPEN) / (Intraday_Open) as each bar is processed."

However, if using Wealth-Data, the adjustment should be EOD_CLOSE / Intraday_CLOSE. They won't always be refer to the same price (as I indicated in Post #2), but the comparison will be closer than the Opening trade since Wealth-Data has the Open on the Primary Market, which is frequently different by several percent from the first trade, which may occur on another exchange.